From majordom  Tue Mar  4 20:31:08 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA08992; Tue, 4 Mar 97 20:31:08 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA08972; Tue, 4 Mar 97 20:30:34 EST
Date: Tue, 4 Mar 1997 20:30:41 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Wei Dai <weidai@eskimo.com>
Cc: David Goldschlag <goldschl@itd.nrl.navy.mil>, shamrock@netcom.com,
        goldschlag@itd.nrl.navy.mil, syverson@nrl.navy.mil,
        daw@cs.berkeley.edu, mccoy@communities.com, onions@itd.nrl.navy.mil
Subject: Re: Onion Routing
In-Reply-To: <Pine.SUN.3.95q.970304164057.8665C-100000@eskimo.com>
Message-Id: <Pine.GSO.3.95.970304202346.9207E-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 4 Mar 1997, Wei Dai wrote:
|>There are no references, other than two pieces of email that describe the
|>original idea.  It is somewhat similar to Onion Routing, but focuses on
|>streams rather than packets.  I implemented a prototype, but then realized
|>that even with constant bandwidth padding, there are a number of attacks
|>possible on my original design.  I'm currently trying to (but not really
|>devoting much time on it) analyze the protocol more clearly. 

Onion Routing is stream based as well.  It runs on top of TCP.  To try
to do this at the packet level is ludicrously large overhead (we have
a reference to a paper that talked about a prototype system that did
it at the IP layer, but there were some BIG problems with overhead and
handling ICMP messages that may be bounced back to the sender for any
packet sent).

|>Besides possible attacks, I'm also concerned about possible abuses of
|>anonymous routing systems.  Have you thought about how to prevent things
|>like hackers breaking into computer systems while maintaining anonymity
|>with the Onion Routers?

That is a political question, and to date, we have tried to only deal
with the technological issues instead of the political ones.  As soon
as we start dealing with political issues, this thing will fall apart.
Back in touch with reality though, we are adding the ability for
either end of an anonymous connection to blacklist sites or restrict
which protocols they support.

I would prefer we follow up this discussion on the onion mailing list.
The list is unmoderated (and brand spanking new :-).  Send mail to
Majordomo@itd.nrl.navy.mil with the line "subscribe onions".  This
will allow us to better track questions/comments/improvements/etc to
the system (ie, make sure no one is out of the loop on possible
changes to the system).  Thanks!

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMxzMxU8Qx019l0ClAQGDQgP/QQFrJe8rMa7RrqonvFc5Yj3bsQGPVdOE
8511aIq2+MheuWEXITz6yqAlm6uoxF0okClHHQQOQqwIoXoKHG1JMkTRBEwrXsCJ
v9fLBY9cBfwpRRSZQsZH8/wRXJPZ+/o6i/ypCRtQ79naOqHuDRrKi/ruw36Z7jIE
iO9pxEHZkls=
=QQqM
-----END PGP SIGNATURE-----


From majordom  Wed Mar  5 00:22:34 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA13239; Wed, 5 Mar 97 00:22:34 EST
Received: from homer.communities.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA13220; Wed, 5 Mar 97 00:22:20 EST
Received: from [205.162.51.35] (pericles.communities.com [205.162.51.35]) by homer.communities.com (8.7.5/8.7.3) with ESMTP id WAA27990; Tue, 4 Mar 1997 22:57:08 -0800
X-Sender: mccoy@mail.communities.com (Unverified)
Message-Id: <v03007802af42b11a63a2@[205.162.51.35]>
In-Reply-To: <199703050150.UAA03701@golem.itd.nrl.navy.mil>
References: <Pine.SUN.3.95q.970304164057.8665C-100000@eskimo.com> (message
 from Wei Dai on Tue, 4 Mar 1997 16:59:24 -0800 (PST))
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 5 Mar 1997 00:21:20 -0500
To: David Goldschlag <goldschl@itd.nrl.navy.mil>
From: Jim McCoy <mccoy@communities.com>
Subject: Re: Onion Routing
Cc: weidai@eskimo.com, onions@itd.nrl.navy.mil
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


David Goldschlag <goldschl@itd.nrl.navy.mil> writes:
>The abuse you noted, that hackers can break into systems anonymously,
>was pointed out in a somewhat happy way by someone who funds computer
>security work.  Anonymous connections will force better defense.

While it may seem like a poor excuse, I am not sure that the identity
and authorization problem is something which the basic system should
concern itself with.  There are a variety of existing methods which can
be attached at the entry and exit points of the system (e.g. SSL client
cert, SPKI certs and credentials, etc.)  It is not as if re-routing
packets through poorly logged systems is that difficult now...

>Our first network topology for onion routing is a closed system: you
>must enter the network somewhere and that point knows where you've
>come from and where you are going.  So there is some tracking there.
>We have another topology where the network knows who you are at entry,
>but not where you are going.  That introduces more concerns.  But you
>still need to identify yourself at entry to the network.

Entry and exit authorization and authentication should be, IMHO, a local
decision.  The exit authorization is probably the most important when
considering the hacking aspect, transport and application level gatekeepers
would probably be best.  The exit point is probably going to be the one
shouldering the burden of responsibility for such problems, so making it
possible for the exit points to enforce a policy regarding this would
probably be the best solution.

jim



From majordom  Wed Mar  5 04:54:04 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16706; Wed, 5 Mar 97 04:54:04 EST
Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16700; Wed, 5 Mar 97 04:53:48 EST
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id EAA26696; Wed, 5 Mar 1997 04:53:47 -0500
Message-Id: <331D42AB.3F54@cs.umass.edu>
Date: Wed, 05 Mar 1997 04:53:47 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <URL:http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
Mime-Version: 1.0
To: onions@itd.nrl.navy.mil
Cc: Wei Dai <weidai@eskimo.com>
Subject: Re: Onion Routing / Policy
References: <Pine.SUN.3.95q.970304164057.8665C-100000@eskimo.com> (message
	 from Wei Dai on Tue, 4 Mar 1997 16:59:24 -0800 (PST)) <v03007802af42b11a63a2@[205.162.51.35]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

David Goldschlag writes:
> Anonymous connections will force better defense.

Anonymous communication mechanisms seem to produce the nice side 
effect of encouraging people to make their local policy decisions 
conscious and explicit. Then they start to realize that widely-
deployed security mechanisms are very useful for exercising local
control over their electronic interactions with other people. The
anonymous remailers have stimulated interest in local mail policy
controls. When you yank away the origination information that people
took for granted (although it was never truly reliable), they have to
face the fact that they're fumbling blindly in the dark until they
take positive steps to inform the authorization process.
-- 
Lewis		http://www.cs.umass.edu/~lmccarth/lmkey.asc
"Overwhelmed by 21 documents? Let LiveTopics guide you!" --AltaVista

From majordom  Wed Mar  5 05:21:36 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA17078; Wed, 5 Mar 97 05:21:36 EST
Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA17070; Wed, 5 Mar 97 05:21:28 EST
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id FAA26891; Wed, 5 Mar 1997 05:21:27 -0500
Message-Id: <331D4927.FF6@cs.umass.edu>
Date: Wed, 05 Mar 1997 05:21:27 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <URL:http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
Mime-Version: 1.0
To: onions@itd.nrl.navy.mil
Cc: Wei Dai <weidai@eskimo.com>
Subject: Re: Onion Routing / Authentication Points
References: <Pine.SUN.3.95q.970304164057.8665C-100000@eskimo.com> (message
	 from Wei Dai on Tue, 4 Mar 1997 16:59:24 -0800 (PST)) <v03007802af42b11a63a2@[205.162.51.35]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Jim McCoy writes:
> It is not as if re-routing
> packets through poorly logged systems is that difficult now...

Agreed -- and I don't really foresee that condition changing.

[...]
> The exit authorization is probably the most important when
> considering the hacking aspect, transport and application level 
> gatekeepers would probably be best.  The exit point is probably going 
> to be the one shouldering the burden of responsibility
[...]

For auditing purposes, it seems to be desirable for a host on the
apparent return path to be able to check its logs and say "they went 
that-a-way" after an intrusion. Then the first host (working 
backwards) that didn't authenticate the prior link (or had its logs
detectably wiped) catches some heat. If the first such host turns out 
to be a .mil then the backdraft is likely to be pretty significant.

I guess I'm arguing that an organization has a motive to authenticate
both at the latest exit point in its administrative domain, and at the 
earliest entry point in its admin. domain. These points may be
distinct. 
-- 
Lewis		http://www.cs.umass.edu/~lmccarth/lmkey.asc
"Overwhelmed by 21 documents? Let LiveTopics guide you!" --AltaVista

From majordom  Fri Mar  7 08:04:53 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA24009; Fri, 7 Mar 97 08:04:53 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA23997; Fri, 7 Mar 97 08:04:44 EST
Date: Fri, 7 Mar 1997 08:04:52 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: Logging...
Message-Id: <Pine.GSO.3.95.970307075617.16881E-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

All-
	Just a question I wanted to bounce off people: What do you all
want to see in terms of logging in a system like this?  There are a
number of very good arguments on both sides of the fence.  Currently,
a *LOT* of information is logged, but this is so we can continue to
debug the system.  By its very nature, this system is a beast to
debug, so we do keep a lot around for now.  My view is that *ALL*
logging that does not report an explicit error in the protocol should
be removed.  This has the side effect of making it impossible to track
a connection back once it is terminated (assuming all core nodes also
discard their internal identifiers or reuse them -- I trash them as
soon as I can right now and reuse is governed by random probability).
If a connection is still in place, then the path can be determined
with the help of all core routers taking part in the connection (a
bitch even at that, but possible).  A few people have commented that
'traceability' may be desirable for legal reasons, but I would argue
the contrary.  Would it not be possible to consider the system as a
Common Carrier in the telephony sense (ie, they cannot be held
responsible for the actions of the users, they are merely a conduit
that anyone can use) or does this then mandate that we have a way to
tap the communications channels (impossible except at the endpoints)?
Comments?

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMyASeE8Qx019l0ClAQHkvgP/e7JZ65QsX5Ik5WAFlyn+U102c0h+lelH
K880Du7bBxIZ8T526akJI7LzFZQY8eNSSqverWl8Jofe4PZ5zWc1pv1VmQKDsCJd
SWKw6rfCa92fqXd6nUxzwaWlu5gKbtWkhguFvbobbC38MnQ7z8utgp+I1stIz8vw
rdAg+hfYd0E=
=brOn
-----END PGP SIGNATURE-----


From majordom  Fri Mar  7 15:11:31 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16179; Fri, 7 Mar 97 15:11:31 EST
Received: from netcom12.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16173; Fri, 7 Mar 97 15:11:24 EST
Received: from sfbayarea (h96-223.ccnet.com [192.215.96.223]) by netcom12.netcom.com (8.6.13/Netcom)
	id MAA16670; Fri, 7 Mar 1997 12:11:22 -0800
Message-Id: <3.0.32.19970307121225.006f05a8@netcom9.netcom.com>
X-Sender: shamrock@netcom9.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 07 Mar 1997 12:12:36 -0800
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>, onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: Re: Logging...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 08:04 AM 3/7/97 -0500, Michael G. Reed wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>All-
>	Just a question I wanted to bounce off people: What do you all
>want to see in terms of logging in a system like this?  There are a
>number of very good arguments on both sides of the fence.  Currently,
>a *LOT* of information is logged, but this is so we can continue to
>debug the system.

Sure. During debugging, logging is required.

>  By its very nature, this system is a beast to
>debug, so we do keep a lot around for now.  My view is that *ALL*
>logging that does not report an explicit error in the protocol should
>be removed. 

I agree.

> This has the side effect of making it impossible to track
>a connection back once it is terminated (assuming all core nodes also
>discard their internal identifiers or reuse them -- I trash them as
>soon as I can right now and reuse is governed by random probability).
>If a connection is still in place, then the path can be determined
>with the help of all core routers taking part in the connection (a
>bitch even at that, but possible).  A few people have commented that
>'traceability' may be desirable for legal reasons, but I would argue
>the contrary. 

The user should assume that all traffic at all sites not under his direct
control is logged except one site. If the system then still provides full
untraceability, it is designed well. If not, you need to rework the design.
This is just like with Mixmasters. You assume that one Mixmaster is not
logging internally, but that it is watched from the outside. You further
assume that all other Mixmasters in the chain may be fully compromised.

In production mode, the operators should not log anything but exceptions.
But the user shouldn't have to rely on this.



-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Sun Mar  9 13:48:47 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA25136; Sun, 9 Mar 97 13:48:47 EST
Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA25128; Sun, 9 Mar 97 13:48:38 EST
Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id NAA01094; Sun, 9 Mar 1997 13:48:31 -0500 (EST)
Date: Sun, 9 Mar 1997 13:48:31 -0500 (EST)
Message-Id: <199703091848.NAA01094@golem.itd.nrl.navy.mil>
From: David Goldschlag <goldschl@itd.nrl.navy.mil>
To: shamrock@netcom.com
Cc: reed@itd.nrl.navy.mil, onions@itd.nrl.navy.mil
In-Reply-To: <3.0.32.19970307121225.006f05a8@netcom9.netcom.com> (message from
	Lucky Green on Fri, 07 Mar 1997 12:12:36 -0800)
Subject: Re: Logging...
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


Regarding logs.  I agree with Michael that we should remove all
logging (except for errors) once we are finished with the limited
test.  But that doesn't address Shamrock's question:

The user should assume that all traffic at all sites not under his direct
control is logged except one site. If the system then still provides full
untraceability, it is designed well. If not, you need to rework the design.
This is just like with Mixmasters. You assume that one Mixmaster is not
logging internally, but that it is watched from the outside. You further
assume that all other Mixmasters in the chain may be fully
compromised. 


We are essentially doing real-time mixing, under the hypothesis that
if there is sufficient traffic, one does not need to delay traffic
very much to do good mixing, nor does one need to add padding.  If the
network is not heavily utilized, we will need to add padding.  The
unanswered question is what is the balance between the delay needed to
do mixing, the utilization level, and padding.  If we need to add lots
of padding even when the network is heavily utilized, then our
approach will not be viable, because it will not use the network
efficiently.  Our goal is a system that many people will use, but that
provides strong protection.

If the first onion router in an anonymous connection is compromised,
then everything is revealed, since (in our current model) the first
onion router knows both endpoints of a connection.

If all onion routers but the first in an anonymous connection are
compromised, then the connection can be tracked back to the first
onion router.  If that onion router lives on a firewall and the
connection originated from inside the firewall, then the source site
will be revealed, but not the particular machine.  If connections to
that onion router are not hidden, then the set of source machines is
revealed also.  This weakness applies to mix based remailers also, I
think, except that the set of source machines may be larger, because
mail may be delayed for a while at the first remailer.

If the first onion router and some intermediate onion router in the
anonymous connection are not compromised, then it is hard to match
incoming to outgoing traffic at the intermediate onion router.  Now if
attacks can be active, and traffic between nodes can be interrupted,
and the uncompromised node does not respond by padding traffic, then
more information can be obtained.

David.

From majordom  Sun Mar  9 18:02:47 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA28209; Sun, 9 Mar 97 18:02:47 EST
Received: from netcom12.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA28197; Sun, 9 Mar 97 18:02:37 EST
Received: from sfbayarea (h96-131.ccnet.com [192.215.96.131]) by netcom12.netcom.com (8.6.13/Netcom)
	id PAA27000; Sun, 9 Mar 1997 15:02:33 -0800
Message-Id: <3.0.32.19970309150344.006f0624@netcom9.netcom.com>
X-Sender: shamrock@netcom9.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sun, 09 Mar 1997 15:04:06 -0800
To: David Goldschlag <goldschl@itd.nrl.navy.mil>
From: Lucky Green <shamrock@netcom.com>
Subject: Re: Logging...
Cc: reed@itd.nrl.navy.mil, onions@itd.nrl.navy.mil, raph@acm.org,
        jeremey@veriweb.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 01:48 PM 3/9/97 -0500, David Goldschlag wrote:
>
>Regarding logs.  I agree with Michael that we should remove all
>logging (except for errors) once we are finished with the limited
>test.  But that doesn't address Shamrock's question:

When are you going to make the source available? I have talked with a
number of folks that are interested in running (improved) onion routers.

[We discussed Onion Routers, Pipe-Net, and Raph Levien's new proposal at
yesterday's monthly Cypherpunks meeting. I am cc'ing some of the
participants.]

>We are essentially doing real-time mixing, under the hypothesis that
>if there is sufficient traffic, one does not need to delay traffic
>very much to do good mixing, nor does one need to add padding.

I believe this hypothesis can not be safely made. Traffic patterns vary
widely, depending on the time of day and other factors. The attacker
doesn't need much correlation to conduct traffic analysis.

The system should be secure from traffic analysis even when there are only
two users on the network. This can be achieved by moving the first proxy on
the user's machine and keeping the data streams constant within each
segment of the network.

>  If the
>network is not heavily utilized, we will need to add padding.  The
>unanswered question is what is the balance between the delay needed to
>do mixing, the utilization level, and padding.  If we need to add lots
>of padding even when the network is heavily utilized, then our
>approach will not be viable, because it will not use the network
>efficiently.  Our goal is a system that many people will use, but that
>provides strong protection.

Using the Pipe-Net approach, the load on the network remains constant until
the pipe is saturated. [Note that the heavier the network usage, the less
padding is added. If the network is fully utilized, no padding is added.]
If you are correct in your assumption that the network will be widely used
than using a Pipe-Net approach will not add much overhead. If however there
will be times of low network usage, the constant bandwidth pipes will
protect the users that use the network at that time.

One question may be what to do if the load saturates the pipe. If that
happens, you can add delays. As long as the last proxy is on the user's
machine, these artificial delays won't create a traffic analysis opportunity.

>If the first onion router in an anonymous connection is compromised,
>then everything is revealed, since (in our current model) the first
>onion router knows both endpoints of a connection.

No router should ever know more than the previous and the next router.
Except of course the "router" sitting on the user's machine, which would
simply be a client side HTTP proxy.

>If the first onion router and some intermediate onion router in the
>anonymous connection are not compromised, then it is hard to match
>incoming to outgoing traffic at the intermediate onion router.  Now if
>attacks can be active, and traffic between nodes can be interrupted,
>and the uncompromised node does not respond by padding traffic, then
>more information can be obtained.

That's why padding is a must.

[Raph, I would encourage you to post your system to this list. It addresses
a different set of problems, but they are certainly related to the issue of
anonymous web browsing.]



-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Mon Mar 10 04:39:31 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA06061; Mon, 10 Mar 97 04:39:31 EST
Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA06054; Mon, 10 Mar 97 04:39:20 EST
Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id BAA09519; Mon, 10 Mar 1997 01:42:57 GMT
Message-Id: <3323671D.7E9F12DE@veriweb.com>
Date: Mon, 10 Mar 1997 01:42:53 +0000
From: Jeremey Barrett <jeremey@veriweb.com>
Organization: VeriWeb Internet Corp.
X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586)
To: shamrock@netcom.com
Cc: David Goldschlag <goldschl@itd.nrl.navy.mil>, reed@itd.nrl.navy.mil,
        onions@itd.nrl.navy.mil, raph@acm.org
Subject: Re: Logging...
References: <3.0.32.19970309150344.006f0624@netcom9.netcom.com>
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Lucky Green wrote:
> 
> At 01:48 PM 3/9/97 -0500, David Goldschlag wrote:
> >
> >Regarding logs.  I agree with Michael that we should remove all
> >logging (except for errors) once we are finished with the limited
> >test.  But that doesn't address Shamrock's question:
> 
> When are you going to make the source available? I have talked with a
> number of folks that are interested in running (improved) onion routers.
> 
> [We discussed Onion Routers, Pipe-Net, and Raph Levien's new proposal at
> yesterday's monthly Cypherpunks meeting. I am cc'ing some of the
> participants.]
> 
> >We are essentially doing real-time mixing, under the hypothesis that
> >if there is sufficient traffic, one does not need to delay traffic
> >very much to do good mixing, nor does one need to add padding.
> 
> I believe this hypothesis can not be safely made. Traffic patterns vary
> widely, depending on the time of day and other factors. The attacker
> doesn't need much correlation to conduct traffic analysis.

This is true, plus even in peak traffic periods, you probably will not
get "even" traffic. It will likely be bursty, or at least it _may_ be
bursty. So traffic analysis may or may not be possible based on the time 
of day and luck of the draw. It would be best to be resistant to
traffic analysis always, as Lucky suggests.

Timing attacks are a concern, though probably hard to implement. If I
can watch traffic entering and leaving the (core) nodes, then I can
pretty well guess, for any given load, who's going where. i.e. if it
takes 3 seconds for a request to enter the network at one point and
pop out at another, then an educated guess about who's talking to
who requires no active attack. That's not to say it's easy.

This also is not affected by constant traffic, unless the constant
traffic is sufficiently "real" traffic that outbound (to "real" hosts) 
connections are created so fast that differentiating them is hard.

Having large numbers of routers certainly makes this much more 
difficult.

> 
> The system should be secure from traffic analysis even when there are 
> only two users on the network. This can be achieved by moving the first
> proxy on the user's machine and keeping the data streams constant 
> within each segment of the network.
> 
> >  If the
> >network is not heavily utilized, we will need to add padding.  The
> >unanswered question is what is the balance between the delay needed to
> >do mixing, the utilization level, and padding.  If we need to add lots
> >of padding even when the network is heavily utilized, then our
> >approach will not be viable, because it will not use the network
> >efficiently.  Our goal is a system that many people will use, but that
> >provides strong protection.
> 
> Using the Pipe-Net approach, the load on the network remains constant 
> until the pipe is saturated. [Note that the heavier the network usage, 
> the less padding is added. If the network is fully utilized, no padding 
> is added.] If you are correct in your assumption that the network will 
> be widely used than using a Pipe-Net approach will not add much 
> overhead. If however there will be times of low network usage, the 
> constant bandwidth pipes will protect the users that use the network at 
> that time.
> 
> One question may be what to do if the load saturates the pipe. If that
> happens, you can add delays. As long as the last proxy is on the user's
> machine, these artificial delays won't create a traffic analysis 
> opportunity.

I don't see what can be learned from a saturated net. If all the data
is real and the net is running at full capacity, then that's optimal.

> 
> >If the first onion router in an anonymous connection is compromised,
> >then everything is revealed, since (in our current model) the first
> >onion router knows both endpoints of a connection.
> 
> No router should ever know more than the previous and the next router.
> Except of course the "router" sitting on the user's machine, which would
> simply be a client side HTTP proxy.

In this case, the client side proxy is the first router. It's compromise
is equal to compromising the first router in the net if no client side
proxies exist.

> 
> >If the first onion router and some intermediate onion router in the
> >anonymous connection are not compromised, then it is hard to match
> >incoming to outgoing traffic at the intermediate onion router.  Now if
> >attacks can be active, and traffic between nodes can be interrupted,
> >and the uncompromised node does not respond by padding traffic, then
> >more information can be obtained.
> 
> That's why padding is a must.

Agreed.

But again, if you take the core Pipe-Net (by core I mean not counting
client side proxies) routers and consider them one black box, then
timing things entering and leaving the black box is dangerous, if
the number of such things is manageable.

BTW I'm very sleepy, so shoot anything that's incoherent or blatantly
obvious :-)

Jeremey.

- -- 
=-----------------------------------------------------------------------= 
Jeremey Barrett                                  VeriWeb Internet Corp.
Crypto, Ecash, Commerce Systems                  http://www.veriweb.com/
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-----BEGIN PGP SIGNED MESSAGE-----

Since I just joined the list, I'm gonna recap what's in my head and
what I think the issues are. Please add or remove items if necessary:

Some potential problems with onion routing as described in the 
"Hiding Routing Information" paper (some of these are addressed in
the paper itself):

 o The assumption that usage will be constant and high may not be not 
   valid

 o Traffic analysis in a non-optimal (i.e. not evenly utilized all
   the time) net will not be difficult (just follow the packets)

   The solution to this seems to be constant utilization by simply
   sending data all the time, real or not.

 o Timing attacks are effective during low-use of the net, even if
   the net is saturated with fake data. (If a manageable number of
   routers exist. Large numbers make this more difficult).

   One possible solution to this would be the initiator sending
   a bunch of fake onions around, so that the endpoint cannot
   easily be indentified. Unfortunately, this might involve _alot_
   of fake onions. However, as the usage of the net increased, the
   number of fakes required would decrease.

 o Some information may be obtained by denial of service attacks at
   particular points. Depending on the number of connections at the
   moment, etc, it may be possible to induce a traceable chain of
   "destroy" messages. This again argues for constant data streams
   between routers.


Some other thoughts:

   All in all, I think a "Pretty Good Onion Router" is a good idea.
   I would love to be able to hit web sites without them knowing
   where I'm coming from, where the performance is good and I'm fairly
   secure in the knowledge that only someone really determined and
   skilled could trace me, if at all. So my suggestion is that once
   a "Pretty Good Onion Router" system is in place, then we focus on
   making it as bulletproof as possible.


   Have "boomerang" (my term, dunno if a real one exists) routes
   been considered? A boomerang route would be forward-only. i.e.
   rather than an onion containing the responder's proxy node as the
   endpoint, it would contain itself. Then the onion would describe
   a forward-only path from a router back to itself. The responder's
   proxy node would get a slightly different packet, identifying
   it as "the" node. Rather than specify both forward and reverse
   crypto operations, only forward would be specified. All operations
   up to the responder's proxy node would be decryption, all subsequent
   operations would be encryption.

   This might have several benefits:

   o The endpoint, even with no dummy data being sent around, is more
     difficult to identify.

   o Intermediate nodes could be given fake responder requests, and
     return data along the circuit just as the real one does. The real
     data would be indistinguishable from the fake. This would also
     further compliate endpoint determination, since all the routers
     appear to be endpoints.

   o Looking at it, the real endpoint is no different at all from the
     fake ones, if fake endpoint requests are sent to all routers. The 
     initiator would need to include a connection id for each router, so 
     the correct data could be indentified.

   Some drawbacks:

   o The initiator must receive all the fake data as well as the real.
     (this might also be a feature)

   o Generating fake requests may not be easy (at least to always be
     believable). What gets sent _to_ the fake connections as "data"?
     (for HTTP, what URL do you ask for?)

   o This may not work very well (or not any better anyway) for anything 
     other than HTTP, NNTP, or similar. (I can't see this working well 
     for telnet)

   o Other as-yet-unforseen things I'm too tired to think of.

Responses and flames please :-)

Jeremey.

- -- 
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Thanks for your summary.

Here is our position about onion routing.

Onion routing provides four mechanisms: 

(1) Mechanisms for maintaining the topology of the network.

(2) Onion routers that support anonymous connections that reliably
carry data bidirectionally between some first onion router and some
last onion router.

(3) An onion creation mechanism that defines and creates the anonymous
connection.

(4) Interfaces between the anonymous connections and other
applications.

We currently provide application level proxies for HTTP, SMTP, and
RLOGIN, and anonymizing versions of those proxies.  Other interfaces
may collect data at the IP level.

Currently, our onion creation mechanism lives on the first onion
router, but it does not need to.  There are trade-offs associated with
the location of that mechanism.

There are three ways to add extra data into the onion routing network.
Onion routers do not pad data in an anonymous connection.  That can be
done outside the system.  Onion routers do not introduce extra
anonymous connections to confuse traffic analysis.  That too can be
done outside the system.  Our implementation of onion routing does
define a padding cell that can carry dummy traffic between two onion
routers.  Our onion routers do not produce such cells, but do ignore
such cells.

Our position on padding is that constant utilization of an onion
routing network may not be necessary to complicate traffic analysis.
We still have to validate this hypothesis.  If constant utilization is
necessary, the system will not scale well, will use network resources
inefficiently, and will not be widely adopted.

It may be necessary to smooth out utilization through the three
padding approaches described above, and onion routing provides an
infrastructure within which these questions can be answered and
solutions explored.

Our goal is not pretty good onion routers.  Our goal is a
communications infrastructure that is resistant to traffic analysis,
that can efficiently deliver traffic throughout the network, and that
will be widely deployed.

David.


From majordom  Mon Mar 10 15:40:18 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA04398; Mon, 10 Mar 97 15:40:18 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA04382; Mon, 10 Mar 97 15:40:08 EST
Date: Mon, 10 Mar 1997 15:40:14 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: Re: Logging...
In-Reply-To: <3.0.32.19970309150344.006f0624@netcom9.netcom.com>
Message-Id: <Pine.GSO.3.95.970310152054.24156D-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk
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NOTE: Cc's trimmed since the onions mailing lists contained all the
      people addressed initially.

On Sun, 9 Mar 1997, Lucky Green wrote:
|>When are you going to make the source available? I have talked with a
|>number of folks that are interested in running (improved) onion routers.

The source will be made available when we can make it available.  The
first cut of tests will be with binary only distribution and these
tests are SOLELY for the purpose of getting some hard numbers on the
performance of the system and identifying some of the bottlenecks --
there is only so much I can do in my lab, and only so many people have
$25k machines at their disposal to run tests...we need some real-world
numbers on real-world systems, on the real-world Internet.  The
system, as it is written today, will most likely undergo some major
structural changes (some are already planned, some more will probably
become evident once we get some more numbers on system performance) in
the weeks to come and it is far to premature to distribute source
widely.

|>[We discussed Onion Routers, Pipe-Net, and Raph Levien's new proposal at
|>yesterday's monthly Cypherpunks meeting. I am cc'ing some of the
|>participants.]

Which cypherpunks meeting are you referring to?  DC?  Bay Area?
Where?  We would be interested in hearing those discussions and
participating in the future if possible...the more feedback we can
get, the better the system will be.

|>>We are essentially doing real-time mixing, under the hypothesis that
|>>if there is sufficient traffic, one does not need to delay traffic
|>>very much to do good mixing, nor does one need to add padding.
|>
|>I believe this hypothesis can not be safely made. Traffic patterns vary
|>widely, depending on the time of day and other factors. The attacker
|>doesn't need much correlation to conduct traffic analysis.

This is true, but this also assumes that said attacker has sniffers at
the entry to *EVERY* onion-router on the internet...miss only one and
you have a problem.  We are not suggesting that padding is not
necessary.  Certainly, there will be times (lots of times) we need to
pad data.  *BUT* just throwing padding at the problem does *NOT* solve
it (this has been shown).

|>The system should be secure from traffic analysis even when there are only
|>two users on the network. This can be achieved by moving the first proxy on
|>the user's machine and keeping the data streams constant within each
|>segment of the network.

Keeping data streams constant on the Internet is infeasible unless
they are of such pathetically low bandwidth as to make them unusable.
Simply put, at the layer of the network stack we are operating at, and
given the current congestion on the major backbones (including packet
loss), I think it is a pipe-dream (pardon the pun) to think you will
be able to hit constant (full) bandwidth with padding.  In terms of
moving the onion creation to the local machine, that is possible (and
even defined) in our system.  As a matter of fact, that is one of the
fundamental shifts that we are looking at making in the system, and it
is documented in some detail in the papers.

|>One question may be what to do if the load saturates the pipe. If that
|>happens, you can add delays. As long as the last proxy is on the user's
|>machine, these artificial delays won't create a traffic analysis opportunity.

Ah, but *WHERE* do the delays appear?  Anywhere down the length of the
circuit for which you have no information about utilization and
therefore you much rely on the system to throttle you down...the
problem does not go away simply by moving the last hop.

|>>If the first onion router in an anonymous connection is compromised,
|>>then everything is revealed, since (in our current model) the first
|>>onion router knows both endpoints of a connection.
|>
|>No router should ever know more than the previous and the next router.
|>Except of course the "router" sitting on the user's machine, which would
|>simply be a client side HTTP proxy.

Yes, and in the topology you just described, the "router" on the
user's machine is the first onion-router, thus only it knows the whole
path.

- -Michael
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On Mon, 10 Mar 1997, Jeremey Barrett wrote:
|> o The assumption that usage will be constant and high may not be not 
|>   valid

This is true.  We really do not know what the demand will be yet for
the service, but if you look at how overloaded the Anonymizer is most
of the time, I think we can assume it will be moderate at the least.

|> o Traffic analysis in a non-optimal (i.e. not evenly utilized all
|>   the time) net will not be difficult (just follow the packets)
|>   The solution to this seems to be constant utilization by simply
|>   sending data all the time, real or not.

As I said before, simple padding does not solve the problem.  The
onion routers themselves know what is pad and what is not (unless you
create dummy connection and pad through the connections in which case
the first and last onion router knows it pad but not the intermediates
and this doesn't solve the link-level padding problem).

|> o Timing attacks are effective during low-use of the net, even if
|>   the net is saturated with fake data. (If a manageable number of
|>   routers exist. Large numbers make this more difficult).
|>
|>   One possible solution to this would be the initiator sending
|>   a bunch of fake onions around, so that the endpoint cannot
|>   easily be indentified. Unfortunately, this might involve _alot_
|>   of fake onions. However, as the usage of the net increased, the
|>   number of fakes required would decrease.

Simply having more endpoints to the system does not increase the
difficulty to track coincidences...you need data moving into and out of
the overall network to make it more difficult.  Either dummy services,
or just meaningless requests on pre-defined protocols.

|> o Some information may be obtained by denial of service attacks at
|>   particular points. Depending on the number of connections at the
|>   moment, etc, it may be possible to induce a traceable chain of
|>   "destroy" messages. This again argues for constant data streams
|>   between routers.

The "Destroy flurry" that we describe when a thick-pipe goes down is a
problem, but it's one that we haven't been able to come up with a good
solution for.  We have a couple of possibilities (including delaying
the destruction of the circuits that went through that thick pipe and
dropping them at random intervals thereafter), but are still looking
at that.

|>   All in all, I think a "Pretty Good Onion Router" is a good idea.
|>   I would love to be able to hit web sites without them knowing
|>   where I'm coming from, where the performance is good and I'm fairly
|>   secure in the knowledge that only someone really determined and
|>   skilled could trace me, if at all. So my suggestion is that once
|>   a "Pretty Good Onion Router" system is in place, then we focus on
|>   making it as bulletproof as possible.

While "Pretty Good" might be good enough for some, we are really
looking to get this right, get a RFC out there, and get this thing
deployed world-wide as soon as possible.  That doesn't allow for
"Pretty Good".  It means we do some experimenting now, draw on the
best and brightest that are available, and get input from people
during this initial period to DO IT RIGHT THE FIRST TIME.  Of course
this means it won't be out next week, but I think the general
population would prefer something that works the first time than an
evolution of shoddy systems that really were never right.

|>   Have "boomerang" (my term, dunno if a real one exists) routes
|>   been considered? A boomerang route would be forward-only. i.e.
|>   rather than an onion containing the responder's proxy node as the
|>   endpoint, it would contain itself. Then the onion would describe
|>   a forward-only path from a router back to itself. The responder's
|>   proxy node would get a slightly different packet, identifying
|>   it as "the" node. Rather than specify both forward and reverse
|>   crypto operations, only forward would be specified. All operations
|>   up to the responder's proxy node would be decryption, all subsequent
|>   operations would be encryption.

I'm not sure I follow this completely (or what the motivation is for it
completely), can you elaborate some more on it?  Thanks!

- -Michael
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Hi,

We are planning to release code this week for testing.  Testsers have
to agree not to redistribute code.  Soon we hope to put the code on a
site that will re-distribute within the US.

It would be useful to start a discussion about what we are trying to
hide and what may do that hiding.  I'm looking for communication
models, attack models, carefully stated requirements, and justified
solutions.

For example, precisely what do we by "assume only a single
uncompromised onion router?"

As another example, if two sites connect (encrypted) to remote onion
routers at roughly the same time, it is more likely that they are
communicating than if they didn't connect at roughly the same time.
This is hard to protect against.

Do we need constant utilization or is smoothing sufficient?

Do we want to add noice to individual connections?

Do we want terminal onion router to terminal onion router padding
(noise connections)?

Do we want padding between neighboring onion routers?


I'm looking to leverage off the expertise in this list, so we can
build strong hiding around the onion routing infrastructure.

Thanks,
David.
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Michael G. Reed wrote:
> 
> |> o Timing attacks are effective during low-use of the net, even if
> |>   the net is saturated with fake data. (If a manageable number of
> |>   routers exist. Large numbers make this more difficult).
> |>
> |>   One possible solution to this would be the initiator sending
> |>   a bunch of fake onions around, so that the endpoint cannot
> |>   easily be indentified. Unfortunately, this might involve _alot_
> |>   of fake onions. However, as the usage of the net increased, the
> |>   number of fakes required would decrease.
> 
> Simply having more endpoints to the system does not increase the
> difficulty to track coincidences...you need data moving into and out of
> the overall network to make it more difficult.  Either dummy services,
> or just meaningless requests on pre-defined protocols.

I agree. But more endpoints does mean you have to monitor more points 
of entry/exit to identify coincidences reliably.

> 
> |>   All in all, I think a "Pretty Good Onion Router" is a good idea.
> |>   I would love to be able to hit web sites without them knowing
> |>   where I'm coming from, where the performance is good and I'm fairly
> |>   secure in the knowledge that only someone really determined and
> |>   skilled could trace me, if at all. So my suggestion is that once
> |>   a "Pretty Good Onion Router" system is in place, then we focus on
> |>   making it as bulletproof as possible.
> 
> While "Pretty Good" might be good enough for some, we are really
> looking to get this right, get a RFC out there, and get this thing
> deployed world-wide as soon as possible.  That doesn't allow for
> "Pretty Good".  It means we do some experimenting now, draw on the
> best and brightest that are available, and get input from people
> during this initial period to DO IT RIGHT THE FIRST TIME.  Of course
> this means it won't be out next week, but I think the general
> population would prefer something that works the first time than an
> evolution of shoddy systems that really were never right.

I agree completely. I intended "Pretty Good" in the spirit of PGP. There
is a danger of trying to solve _too_ much and never getting anything
done. That's not to say I think that will happen here.

> 
> |>   Have "boomerang" (my term, dunno if a real one exists) routes
> |>   been considered? A boomerang route would be forward-only. i.e.
> |>   rather than an onion containing the responder's proxy node as the
> |>   endpoint, it would contain itself. Then the onion would describe
> |>   a forward-only path from a router back to itself. The responder's
> |>   proxy node would get a slightly different packet, identifying
> |>   it as "the" node. Rather than specify both forward and reverse
> |>   crypto operations, only forward would be specified. All operations
> |>   up to the responder's proxy node would be decryption, all 
> |>   subsequent operations would be encryption.
> 
> I'm not sure I follow this completely (or what the motivation is for it
> completely), can you elaborate some more on it?  Thanks!
> 

Instead of a connection with two endpoints, the idea is a connection
with
only one (obvious) endpoint. The first router, let's say on the user's
machine, creates an onion which identifies a chain of routers such
that it (the first router) is the _endpoint_ of the route. Now it sends
a "data" message along the route. The router which receives a data
message in the clear (after applying the crypto operation) is the one
which goes and satisfies the data request. Once the data is retrieved,
it applies an outgoing crypto operation and sends the data along the
route, still in the forward direction. No messages travel backwards.

A simple analogy is a circle as opposed to a line.

I can see a few potential advantages here:

 o The node which actually satisfies the data request cannot be
identified
   simply by being the terminating node of a connection, since the 
   terminating node is the same as the first router.

 o You can't "follow" packets to one end or the other because they
always 
   complete the route back to the sender.

 o Rather than "destroy" messages in the event a router in the circuit
   dies, "reroute" messages could be used. The reroute messages would
   make their way along the circuit, resulting in the first router
   sending another onion, such that the previous "endpoint", which may
   have data waiting to send on the route, is still identified as the
   endpoint. The identity of the "endpoint" router is still not
   given away. In a point to point route, if destroy messages can
   be traced, then the endpoint is identified.

 o This scheme may make sending dummy traffic better/easier.

I'm throwing this idea on the table, not necessarily suggesting it's
use. I'm not entirely sure what the consequences of it would be, I need
to think about it more. The idea is somewhat analagous to nym.alias.net
and similar nym servers, where the nym is the "endpoint", the remailer
path to the nym is the route up to the "endpoint", and the reply block
is the route after the "endpoint". I put "endpoint" in quotes because
it is not the actual end of the route. Any thoughts welcome.

Jeremey.

- -- 
=-----------------------------------------------------------------------= 
Jeremey Barrett                                  VeriWeb Internet Corp.
Crypto, Ecash, Commerce Systems                  http://www.veriweb.com/

PGP Key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64
=-----------------------------------------------------------------------=

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMySGYi/fy+vkqMxNAQFSGgQAja2167/+biJTY4AphGhTK4IunI7GJvmQ
S7wJrxQD6z/W9kaDK105xLwkdx7WyHUol6NycU6CZlL5PeCFpcOr9q9CI1j6IUOE
kX1RnO46o7lAaAi+sdKbesJoZbx1/8nWs9AoobKfk7+Kz26VUPWRo492BYYKRrf5
pz2TjasgBF8=
=FRIa
-----END PGP SIGNATURE-----

From majordom  Mon Mar 10 17:16:00 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA09228; Mon, 10 Mar 97 17:16:00 EST
Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA09222; Mon, 10 Mar 97 17:15:53 EST
Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id OAA10255; Mon, 10 Mar 1997 14:19:24 -0800
Message-Id: <332488E9.69573EE3@veriweb.com>
Date: Mon, 10 Mar 1997 22:19:21 +0000
From: Jeremey Barrett <jeremey@veriweb.com>
Organization: VeriWeb Internet Corp.
X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586)
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Cc: onions@itd.nrl.navy.mil
Subject: Re: Onion routing: thoughts
References: <Pine.GSO.3.95.970310154631.24156E-100000@banana-jr.itd.nrl.navy.mil>
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Michael G. Reed wrote:
> 
> I'm not sure I follow this completely (or what the motivation is for it
> completely), can you elaborate some more on it?  Thanks!
> 

I don't think my last explanation was so clear either. Simply put: the
return path from responder to initiator need not be the same as the
path from initiator to responder. Probably the best way to do this is
for the initiator to identify himself as the endpoint in the onion
he sends around.

Jeremey.

- -- 
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Jeremey Barrett                                  VeriWeb Internet Corp.
Crypto, Ecash, Commerce Systems                  http://www.veriweb.com/
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From majordom  Mon Mar 10 17:38:36 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10100; Mon, 10 Mar 97 17:38:36 EST
Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10094; Mon, 10 Mar 97 17:38:30 EST
From: syverson@itd.nrl.navy.mil (Paul Syverson)
Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id RAA09625; Mon, 10 Mar 1997 17:38:28 -0500 (EST)
Date: Mon, 10 Mar 1997 17:38:28 -0500 (EST)
Message-Id: <199703102238.RAA09625@carnap.itd.nrl.navy.mil>
To: jeremey@veriweb.com
Subject: Re: Onion routing: thoughts
Cc: onions@itd.nrl.navy.mil
X-Sun-Charset: US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk



> 
> I don't think my last explanation was so clear either. Simply put: the
> return path from responder to initiator need not be the same as the
> path from initiator to responder. Probably the best way to do this is
> for the initiator to identify himself as the endpoint in the onion
> he sends around.
> 
That's one possibility. Another that is mentioned in some of our papers
but won't appear on the first code release is a reply onion.
Basically, this is an onion that the initiator can send to a particular
responder (or broadcast or multicast it from the far end of an onion
route, or even post anonymously). It identifies the first node to which
it should be sent and, when used, creates an anonymous connection back
to the initiator.  Once the connection is established, it is as if the
initiator had created it (in terms of how data is processed). The
advantage here is that the initiator need not identify himself to give
the responder a different route back to himself.  And, he need not
trust the responder to protect the anonymity of that route.  We have
mostly considered this from the perspective of allowing, e.g., replies
to email, especially after the initial connection is gone.  Or,
allowing replies to anonymously posted requests. You raise an
interesting idea that I  don't recall previously discussing with my
colleagues: viz using a reply onion in the context of the connection
through which it was sent.

aloha,
Paul

From majordom  Mon Mar 10 19:07:55 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA12338; Mon, 10 Mar 97 19:07:55 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA12332; Mon, 10 Mar 97 19:07:48 EST
Date: Mon, 10 Mar 1997 19:07:54 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: Re: Onion routing: thoughts
In-Reply-To: <199703102238.RAA09625@carnap.itd.nrl.navy.mil>
Message-Id: <Pine.GSO.3.95.970310184859.27424A-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Mon, 10 Mar 1997, Paul Syverson wrote:
|>> I don't think my last explanation was so clear either. Simply put: the
|>> return path from responder to initiator need not be the same as the
|>> path from initiator to responder. Probably the best way to do this is
|>> for the initiator to identify himself as the endpoint in the onion
|>> he sends around.
|>> 
|>That's one possibility. Another that is mentioned in some of our papers
|>but won't appear on the first code release is a reply onion.
|>Basically, this is an onion that the initiator can send to a particular
|>responder (or broadcast or multicast it from the far end of an onion
|>route, or even post anonymously). It identifies the first node to which
|>it should be sent and, when used, creates an anonymous connection back
|>to the initiator.  Once the connection is established, it is as if the
|>initiator had created it (in terms of how data is processed). The
|>advantage here is that the initiator need not identify himself to give
|>the responder a different route back to himself.  And, he need not
|>trust the responder to protect the anonymity of that route.  We have
|>mostly considered this from the perspective of allowing, e.g., replies
|>to email, especially after the initial connection is gone.  Or,
|>allowing replies to anonymously posted requests. You raise an
|>interesting idea that I  don't recall previously discussing with my
|>colleagues: viz using a reply onion in the context of the connection
|>through which it was sent.

Actually, we did entertain the possibility of asymmetric routes at one
time but discarded them for a couple of reasons:

1) In your earlier argument, you said something to the effect "each
onion router decrypts his layer and the onion-router that gets
plaintext knows he has to respond" -- PROBLEM.  How do you know you
have plaintext?  Imbedded CRC or Hash in each DATA cell?  This is a
*LOT* of overhead, (cell data payload is 44 bytes -- to accommodate
ATM, we would need to decrease this for every byte of hash
stored...not the kind of tradeoff I really want to make right now),
and potentially buys you nothing (there is the finite chance that a
still encrypted cell could hash correctly and match causing an onion
router to mis-think he's the recipient...small, but possible chance).
This actually came up when we considered how to send in-band commands
within DATA cells to control intermediate onion routers.  The idea was
shot down since we could figure out how to do it without adding
another cell type (which we didn't want to do since it would expose
information and be trackable by onion-routers along the route).

2) Crypto Overhead.  Remember, we're think real-time, or near
real-time applications here.  We already spend a staggering amount of
time on our RSA operations...this is still true even with hand coded
assembly implementations for the V9 UltraSparc architecture and
running it on dual processor Ultra2 machines...Five RSA encrypt
operations is already a major burden, but ten would probably be
unbearable...if this is only for padding/garbage data and is not done
too frequently, it would be acceptable, but for every connection, I
think it would kill us via the crypto overhead.  Now if we move to
hardware for the crypto, or if the pentium assembly version proves to
be faster (we think it should be on a comparable MHz machine, but have
yet to try to port this to Solaris x86), this may no longer be the
case.

3) The longer the chain, the higher the probability that any one
"thick pipe" going down will kill your connection.  Plus, you start to
run into the possibility of going through a think pipe multiple times
REALLY killing overall system bandwidth by just bouncing back and
forth.  I'm not saying 5 hops is the magic number (really, I don't
even remember how we came up with 5 in the current implementation, but
it seemed like a good count at the time), but I would be *VERY*
surprised if anyone suggested less than 5 hops, and many more doesn't
seem to buy you that much.  Remember, you only need to trust that ONE
onion router out there in the world that you route through is behaving
to have a secure connection (that and, of course, the first node being
uncompromised).  If you can't trust 40% on the onion routers in the
world (really 20% if you don't include your first hop which you must
trust with your life :-), then we have a larger problem to deal with.

I'm not degrading the idea, it has some interesting applications that
the system could probably use...these were just the reasons we shot it
down before in our discussions...if I've missed anything (or there is
a good counter argument), please clue me in :-) This is the kind of
discussions we're hope to happen -- ones that open doors that we
missed, or shed some light to you all as to why we made some of our
design decisions.  Thanks!

- -Michael
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From majordom  Mon Mar 10 21:04:48 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA14634; Mon, 10 Mar 97 21:04:48 EST
Received: from mail.eskimo.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA14628; Mon, 10 Mar 97 21:04:39 EST
Received: from eskimo.com (eskimo.com [204.122.16.13]) by mail.eskimo.com (8.7.6/8.6.12) with SMTP id SAA05083 for <onions@itd.nrl.navy.mil>; Mon, 10 Mar 1997 18:04:27 -0800 (PST)
Date: Mon, 10 Mar 1997 18:03:26 -0800 (PST)
From: Wei Dai <weidai@eskimo.com>
To: onions@itd.nrl.navy.mil
Subject: Re: Onion routing: thoughts
In-Reply-To: <199703101613.LAA01552@golem.itd.nrl.navy.mil>
Message-Id: <Pine.SUN.3.96.970310173233.16295A-100000@eskimo.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

On Mon, 10 Mar 1997, David Goldschlag wrote:

> Our position on padding is that constant utilization of an onion
> routing network may not be necessary to complicate traffic analysis.
> We still have to validate this hypothesis.  If constant utilization is
> necessary, the system will not scale well, will use network resources
> inefficiently, and will not be widely adopted.

I think it should be easy to show that constant utilization is necessary.
It is the case for Chaum's Mix-Net (see
http://www.eskimo.com/~weidai/traffic.txt), and Onion Routing seems
closely related.  I am convinced that anonymous routing cannot be
relatively efficient.  Indeed it may be worse than you expect - to defend
against certain active attacks (that introduce errors into the network and
analyze their propagation and correction) it may be necessary to propagate
errors throughout the network so that local errors are made global.

> Our goal is not pretty good onion routers. Our goal is a 
> communications infrastructure that is resistant to traffic analysis,
> that can efficiently deliver traffic throughout the network, and that
> will be widely deployed.

Since you are so serious about getting it right the first time, I think a
formal proof of security for your protocol would be extremely helpful.  It
could be done, perhaps, by following the approaches of David Chaum (for
DC-Net) and Dan Simon (for Mix-Net).  The proof for Onion Routing may be
much more difficult, but it would be especially useful considering the
large range of possible attacks and the ease of overlooking a protocol
flaw.

Whether or not an anonymous routing system will be widely deployed is not
simply a technical issue.  I think it also depends on political realities
and economic incentives.  I am glad (but also very curious) that the Navy
should show so much interest in it.  Certainly it improves the chances
quite a bit.

Wei Dai



From majordom  Tue Mar 11 02:43:55 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA20833; Tue, 11 Mar 97 02:43:55 EST
Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA20827; Tue, 11 Mar 97 02:43:45 EST
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id CAA27693 for <onions@itd.nrl.navy.mil>; Tue, 11 Mar 1997 02:43:44 -0500
Message-Id: <33250D30.167E@cs.umass.edu>
Date: Tue, 11 Mar 1997 02:43:44 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <URL:http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
Mime-Version: 1.0
To: Onion Routing Mailing List <onions@itd.nrl.navy.mil>
Subject: Re: Onion routing: thoughts
References: <Pine.SUN.3.96.970310173233.16295A-100000@eskimo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Wei Dai writes:
> I am convinced that anonymous routing cannot be relatively efficient.  
> Indeed it may be worse than you expect - to defend against certain 
> active attacks (that introduce errors into the network and analyze 
> their propagation and correction) it may be necessary to propagate
> errors throughout the network so that local errors are made global.

In the general case, I suspect this is true. One general type of tactic
of an active traffic analyst is to cause some parts of the anonymizing 
network to offer different service quality than others for a spell, and 
deduce information from the results. Any active attacker worth its salt
can always degrade service quality somewhere in the anon-net. So any
successful defensive attempt to balance the service quality across all
the nodes must involve adjusting some nodes' service quality downwards
to meet the current minimum level. 

In the worst case a node somewhere has crashed (i.e. suspended service 
for a long time period relative to the usual delivery interval), in 
which case it seems that the entire anon-net needs to grind to a halt 
temporarily. (Some out-of-band mechanism must communicate updated local
service quality information reliably and quickly.) As the anon-net 
scales up, the mean-time-to-mandated-temporary-failure of the whole
anon-net soars, assuming independent node failures. Experience with the 
Mixmaster network, at least, suggests that the mean-time-to-failure of a 
single node may be surprisingly short in practice. 

[...]
> by following the approaches of David Chaum (for DC-Net) 
> and Dan Simon (for Mix-Net).
[...]

Can you give pointers to Dan Simon's work regarding MIXes? I didn't
realize he had looked at this.
-- 
Lewis		http://www.cs.umass.edu/~lmccarth/lmkey.asc
Onion recipes: http://www.plntationprod.com/Documents/recipe.html

From majordom  Tue Mar 11 16:47:26 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA27366; Tue, 11 Mar 97 16:47:26 EST
Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA27358; Tue, 11 Mar 97 16:47:15 EST
Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id NAA10929; Tue, 11 Mar 1997 13:50:49 -0800
Message-Id: <3325D3B6.10ED6A29@veriweb.com>
Date: Tue, 11 Mar 1997 21:50:46 +0000
From: Jeremey Barrett <jeremey@veriweb.com>
Organization: VeriWeb Internet Corp.
X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586)
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Cc: onions@itd.nrl.navy.mil
Subject: [LONG] Re: Asymmetric routes
References: <Pine.GSO.3.95.970310184859.27424A-100000@banana-jr.itd.nrl.navy.mil>
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Michael G. Reed writes:
> Actually, we did entertain the possibility of asymmetric routes at one
> time but discarded them for a couple of reasons:
> 
> 1) In your earlier argument, you said something to the effect "each
> onion router decrypts his layer and the onion-router that gets
> plaintext knows he has to respond" -- PROBLEM.  How do you know you
> have plaintext?  

For one, you know you are the responder. So on any given route, if
you're the responder, then you must have plaintext. Alternatively,
one bit in the data itself would do.

> Imbedded CRC or Hash in each DATA cell?  This is a
> *LOT* of overhead, (cell data payload is 44 bytes -- to accommodate
> ATM, we would need to decrease this for every byte of hash
> stored...not the kind of tradeoff I really want to make right now),
> and potentially buys you nothing (there is the finite chance that a
> still encrypted cell could hash correctly and match causing an onion
> router to mis-think he's the recipient...small, but possible chance).
> This actually came up when we considered how to send in-band commands
> within DATA cells to control intermediate onion routers.  The idea was
> shot down since we could figure out how to do it without adding
> another cell type (which we didn't want to do since it would expose
> information and be trackable by onion-routers along the route).

If a small header is prepended to the data and then treated as data
in crypto operations, no information should be leaked. Certainly
a hash or CRC just to figure out if you have plaintext would be bad
and wasteful. Perhaps I'm missing something though.

Here's what I've got in my head at the moment. Please point out flaws.
I'm not sure myself that this is useful. It may only be interesting. :-)

 o Initiator creates a circular route back to himself by sending 
   a simple onion (no "reply" onion as such) which traces a route
   back to himself. No other router is aware of being the responder.

 o Data messages look like this:
   
   -----------------
   | HDR | DATAMSG |
   -----------------

   Where HDR is the "visible" header (routers use this to identify
   the message as "data".

   DATAMSG looks like this:

   ------------------
   | DATAHDR | DATA |
   ------------------

   Where DATAHDR is 1 byte or so. Basically just bits set or not
   set. One of the bits is the plaintext bit. Another would be
   the ignore bit. Maybe other stuff.

 o The initiator choose one of the routers on the circuit as the
   responder. The initiator applies crypto operations to the data
   message to send such that the chosen responder gets plaintext.
   Included with the first data message is a set of crypto operations
   for the chosen responder to apply to any data it sends along the
   route. (or perhaps that is the only data in the first data message).

 o Using 2 intermediate hops (not including initiator or responder),
   data messages look like this:

   --------------------------------------------
   | HDR | DATAHDR | DATAHDR | DATAHDR | DATA |
   --------------------------------------------

   Since the initiator has applied 3 crypto operations to the
   final DATAHDR and DATA, neither intermediate router knows who
   has the plaintext. And the initiator has applied 2 crypto operations
   to the second DATAHDR, so the first intermediate router doesn't
   know what the second has either. Both the first and second DATAHDR
   fields are 0 (or at least the plaintext bit and ignore bits are
   not set). The third DATAHDR has the plaintext bit set. Again, this
   is just an onion with layers being peeled off (but no RSA). Padding
   could be added to make it difficult to deduce the number of hops.

 o When the responder gets the data message, it applies the normal 
   crypto operation and obtains plaintext. The responder immediately 
   passes the same data message along the rest of the route by applying
   the "reply-block" crypto operations in succession, and creating
   the necessary DATAHDR fields (which involves applying the correct
   number of crypto operations to them as well). In the DATAHDR which
   will reach the initiator, the plaintext _and_ ignore bits are set.
   The only knowledge the responder gains is the length of the return
   route.

 o The initiator gets the same data message it sent to the responder,
   but now with both plaintext and ignore bits set. It discards and does 
   not forward the message.

 o When the responder has data ready to send to the initiator, it
   constructs DATAHDR's again, but with the plaintext bit and _not_
   the ignore bit set (in the last DATAHDR). 

 o Much the same process repeats, but the responder is now acting
   like the initiator. The initiator gets the response data, and
   gives it to the application or whoever. It also sets the ignore
   bit and sends the data back to the responder, who discards it.

In this way, all messages always complete the circuit, making the
responder difficult to identify. In fact, it is difficult to 
distinguish a response from a request (I realize these terms
are more applicable to HTTP-like protocols than things like telnet).

The same route can be reused, even with different responders.

> 
> 2) Crypto Overhead.  Remember, we're think real-time, or near
> real-time applications here.  We already spend a staggering amount of
> time on our RSA operations...this is still true even with hand coded
> assembly implementations for the V9 UltraSparc architecture and
> running it on dual processor Ultra2 machines...Five RSA encrypt
> operations is already a major burden, but ten would probably be
> unbearable...if this is only for padding/garbage data and is not done
> too frequently, it would be acceptable, but for every connection, I
> think it would kill us via the crypto overhead.  Now if we move to
> hardware for the crypto, or if the pentium assembly version proves to
> be faster (we think it should be on a comparable MHz machine, but have
> yet to try to port this to Solaris x86), this may no longer be the
> case.

Yes, double the RSA operations is a problem. If routes can be reused
significantly, this is less of a problem. 

> 
> 3) The longer the chain, the higher the probability that any one
> "thick pipe" going down will kill your connection.  Plus, you start to
> run into the possibility of going through a think pipe multiple times
> REALLY killing overall system bandwidth by just bouncing back and
> forth.  I'm not saying 5 hops is the magic number (really, I don't
> even remember how we came up with 5 in the current implementation, but
> it seemed like a good count at the time), but I would be *VERY*
> surprised if anyone suggested less than 5 hops, and many more doesn't
> seem to buy you that much.  Remember, you only need to trust that ONE
> onion router out there in the world that you route through is behaving
> to have a secure connection (that and, of course, the first node being
> uncompromised).  If you can't trust 40% on the onion routers in the
> world (really 20% if you don't include your first hop which you must
> trust with your life :-), then we have a larger problem to deal with.
> 

The longer the route, the more potential it will fail. That is always
going to be the case. Breaks in the chain can be rerouted around so that
no data is lost (if the mechanisms are in place. i.e. the initiator
would need to send a connection identifier as part of the data to
the responder. Then the same identifier could be used to replace
the route with another).

For remailers, I rarely use more than 3 hops. I'm not sure what the
magic number is for onion routers, but 5 seems reasonable.

Jeremey.

- -- 
=-----------------------------------------------------------------------= 
Jeremey Barrett                                  VeriWeb Internet Corp.
Crypto, Ecash, Commerce Systems                  http://www.veriweb.com/
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Answering my own question, I noticed Dan Simon's Crypto `96 paper
"Anonymous Communication and Anonymous Cash", which concentrates on
the latter topic. It includes a reference to a STOC `93 paper by
Rackoff & Simon: "Cryptographic Defense Against Traffic Analysis".
-- 
Lewis		http://www.cs.umass.edu/~lmccarth/lmkey.asc
"Overwhelmed by 21 documents? Let LiveTopics guide you!" --AltaVista
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At 04:55 PM 3/10/97 -0500, David Goldschlag wrote:
>
>Hi,
>
>We are planning to release code this week for testing.  Testsers have
>to agree not to redistribute code.  Soon we hope to put the code on a
>site that will re-distribute within the US.

I am a US citizen living in the US and would appreciate any source you have.

>It would be useful to start a discussion about what we are trying to
>hide and what may do that hiding.  I'm looking for communication
>models, attack models, carefully stated requirements, and justified
>solutions.

Seems I am going to  have to write that paper after all...

>For example, precisely what do we by "assume only a single
>uncompromised onion router?"

Assume the adversary monitors all in and outgoing connections. Further
assume, the adversary operates all but one core onion router.

>As another example, if two sites connect (encrypted) to remote onion
>routers at roughly the same time, it is more likely that they are
>communicating than if they didn't connect at roughly the same time.
>This is hard to protect against.

That's where constant bandwidth _will_ make the difference.

>Do we need constant utilization or is smoothing sufficient?

Smoothing is insufficient. Traffic analysis is a statistical attack. With
"smoothing" you just force the attacker to obtain more data.

>Do we want to add noice to individual connections?

Absolutely.

>Do we want terminal onion router to terminal onion router padding
>(noise connections)?

That might  be a good idea. But don't look at it as noise. If the circuits
will be constantly saturated, as you predict, padding will not be needed.

>Do we want padding between neighboring onion routers?

Sure.

>
>I'm looking to leverage off the expertise in this list, so we can
>build strong hiding around the onion routing infrastructure.

I don't know anybody that has longer and deeper thought about these issues
than the subscribers to this list. Onion routing  is a good idea. It just
needs to take some other research into account.



-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi
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-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 12 Mar 1997, Lucky Green wrote:
|>>For example, precisely what do we by "assume only a single
|>>uncompromised onion router?"
|>
|>Assume the adversary monitors all in and outgoing connections. Further
|>assume, the adversary operates all but one core onion router.

If this is the assumption, then everything is a moot point.  If some
adversary operates all but one core onion router he KNOWS with 100%
certainty where the connection originated though.  Then it is only a
matter of time and watching (how carefully it can be watched may vary)
that onion router or doing other statistical attacks on the (now) known
plaintext coming out of all of the nodes before he knows everything.
This is ludicrous.  If you really can't trust some percent of the
onion routers out there in the world (even half), then the whole
effort is a waste in the first place.  By "trust" I don't mean
completely trust in that you would use them as your first hop, but
trust at least to the level that they are not actively attacking you
and are behaving relatively well.  You only need one completely honest
node farther down stream to make the link passively untraceable (and
depending on the implementation one may be sufficient to make it
actively untraceable, but I'm not positive about that).

|>>As another example, if two sites connect (encrypted) to remote onion
|>>routers at roughly the same time, it is more likely that they are
|>>communicating than if they didn't connect at roughly the same time.
|>>This is hard to protect against.
|>
|>That's where constant bandwidth _will_ make the difference.

No, constant bandwidth makes absolutely NO difference in this
situation.  This is an attack which looks at coincidences of NEW
connections going IN TO and OUT OF the network...not data flow within
the network, but timing on new connections.  Bandwidth means nothing
here.

|>>Do we need constant utilization or is smoothing sufficient?
|>
|>Smoothing is insufficient. Traffic analysis is a statistical attack. With
|>"smoothing" you just force the attacker to obtain more data.

See my next message regarding bandwidth concerns...

|>>Do we want to add noice to individual connections?
|>
|>Absolutely.
	
This can be done a number of ways including: 1) letting the higher
level protocol do it, 2) Inserting it into DATA cells somehow
(possibly by having cells with illegal lengths...only the last router
would be able to determine this, which might, in turn, give you some
more information to attack the connection), or 3) Adding a new cell
type (BAD idea since it introduces markers that can be tracked
independent of the other cell types).  To somewhat quote Monte Python,
"#3 is right-out".  Furthermore, I really have to think some more
about #2 before I would consider adding it.  #1 is by far the best,
but we are trying to coexist with UNMODIFIED internet applications, so
this is difficult.

|>>Do we want padding between neighboring onion routers?
|>
|>Sure.

Inter-node padding does not solve the problem of "bad" nodes.  It will
help confound external observers, but a bad node will always know what
is padding on node to node padding.  End to end padding could be
hidden from all but the last node, and protocol padding could be
hidden from all nodes.

|>I don't know anybody that has longer and deeper thought about these issues
|>than the subscribers to this list. Onion routing  is a good idea. It just
|>needs to take some other research into account.

Research or practical experience?  We are researchers.  That is our
job description.  That is what we get paid to do.  There are more
PhD's walking around this base than some college campuses.  We publish
constantly in academic circles, we attend conferences, we participate
in the larger academic world.  Please do not assume that since we work
for the government that we are uninformed, undereducated, GAK-loving
idiots.  What we lack is the practical experience in this area -- most
of what we do is theory, theory, theory...very little applied (at
least in the computer security area).  Thus the prototype where we've
already learned a great deal about where the theoretical models break
down in the real world.  Thus all the discussions with people running
other MIX variants in the world (both in research labs and actually
out there on the Internet).  Thus the need for a wider participation
and the push for a general RFC that can be accepted by the whole
Internet community.  Please don't view this as an "us vs. them"
environment...we want the same level (and possibly even higher level)
of security that you want out of this system...help us do that.  Sorry
for the venting, but I've received one to many emails in the last two
weeks from very uninformed people that have just rubbed me the wrong
way.

- -Michael
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-----BEGIN PGP SIGNED MESSAGE-----

All,
	There have been a number of discussions about padding and
bandwidth usage.  I just want to point out some technical arguments
that we need to consider when designing how the system will pad and to
what extent padding can be achieved.

	First is that we are running on top of a reliable delivery
mechanism of which we have little, if no, control -- namely TCP/IP.
We do not have direct access to the outbound wire like a real router
does, so saying things like "we will use or pad to 100% bandwidth" is
really meaningless.  Padding "to full network or link capacity" only
makes sense in terms of actual control of the wire.  Since we cannot
achieve real control of the wire in our implementation, we need to
look at a different definition.

	One possible solution is to place onion routers on dedicated
links to the Internet.  Not really likely, and not really a viable
option.  Another solution is to predefine and reserve some amount of
guaranteed capacity between nodes.  While this is possible with ATM
and will be possible with IPv6 in general, it is not possible on the
current Internet.  So again, we need to weaken our definition of what
capacity and usable bandwidth are.

	If we do "data smoothing", we can fluctuate bandwidth with
available capacity of the Internet.  I'm not talking real short term
smoothing, but prolonged smoothing where we change individual link
utilization over time with regard to how much traffic we are sending,
and how much traffic exists on the physical links outside of our
system.  I think data smoothing offers a more robust system than just
enforcing a hard capacity since that hard capacity would have to be
based on the slowest, most unreliable link in the system.  Remember,
we are running on top of TCP/IP...there will be packet loss, packet
rerouting, packet retransmission.  We need the ability to back-off
nodes, or else we run the risk of swamping network links in our effort
to attain perfect utilization of whatever capacity we define.

	What it all really comes down to is what our threat model is,
and what we can do on the existing Internet.  I think it is
unreasonable to wait for IPv6, or to say we will only deploy on ATM
clouds.  Furthermore, I think it is unreasonable to enforce
artifically low link capacities because of one bad link somewhere.  I
urge people to comment on all of this.

- -Michael
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I wanted to put in my two cents on some of the topics here, even
though I'm a bit swamped right now. I'll start with a few comments about
what it means to successfully analyze anonymized traffic, outline a few
attacks that seem fruitful, add a few words about "constant bandwidth"
and (for those who have the patience) end with an invitation.

   It seems to me that the best way to model traffic analysis is
_distinguishability_. Is it possible to distinguish, from observable
traffic patterns, the case when Alice is browsing Bob's homepage from
the case when Alice is not? More formally, what is the probability that
an adversary would make the correct guess. If that's significantly
better than chance, then traffic analysis is in some sense feasible. Of
course, the powers of the adversary depend on what we're trying to model
(passively observing some traffic, observing all traffic, actively
inserting traffic, operating compromised onion routers, etc.).

   This may seem like an obvious definition of traffic analysis, but it
gets us closer to the way cryptographic primitives are defined (PRNGs
come to mind), and has some implications for how to prove resistance to
traffic analysis. More on this later when I touch on constant bandwidth.

   Now for some attacks. The first attack assumes passive observing of
traffic volume at all endpoints. No assumptions are made about the
center portion. Thus, the central portion can be implemented as onion
routing, DC-nets, or whatever, and is modelled simply as a probability
distribution of time delays. For anonymous Web browsing, performance
dictates that the mean is fairly small (on the order of a few seconds),
and the random nature of onion routing mixing suggests that a Gaussian
distribution will be fairly accurate.

   Given these assumptions, traffic analysis reduces to a signal
processing problem - separating the signal from the noise. The signal is
right there for all to see (a bump in traffic at Alice, followed by a
bump in traffic a few seconds later at Bob), but may possibly be
obscured by the noise.

   A first cut at the problem is simply to calculate a correlation
matrix of all inputs to the network with all outputs. To improve the
accuracy of the correlation, the input events are convolved (in time)
with the model of the anonymizing network. This convolution also makes
it easy to deal with discrete event traffic flows as opposed to
continuous flows.

   The resulting correlation matrix will contain the desired signal, but
will also contain quite a bit of noise. In particular, correlations
between patterns of browsing will cause spurious positive signals in the
matrix (more concretely, if Alice browses the Dilbert page every morning
when she gets to work, and Bob browses CNN, then the correlation matrix
will show positive numbers for Alice/CNN and Bob/Dilbert). I haven't
gone into the math, but I think it should be possible to remove much of
this cross-correlation noise. Most crudely, the cross-correlation noise
will be concentrated in low frequencies, so it should be possible to
simply filter it out. On the other hand, we're assuming that all traffic
volumes are known, so it should be possible to estimate the
cross-correlations accurately and correct for them. Eric Hughes has
suggested entropy optimization techniques (of roughly the same kind as
used to reconstruct images in computed tomography), and it seems likely
that this approach would be fruitful.

   As a research topic, the next obvious place to look is the
information content in Web browsing patterns. The low frequency
components will be dominated by noise, and the high frequency components
(i.e. finer than a few seconds) will be filtered out by the mixing
process. I believe that there is still plenty of information content in
between, but ultimately this has to be determined empirically.

   Adding active attacks can help. The present-day Web makes these quite
easy. For example, Java applets which refresh information periodically
are becoming popular. It would be easy for such an applet to modulate
the timing so as to maximize the information content and minimize
cross-correlation with other traffic patterns. No doubt the design of
CDMA phones can provide design inspiration.

   One characteristic of this attack is that integration over longer
time periods helps. In general, the signal will scale linearly with the
number of samples, while the noise will only scale as the square root.
Thus, by doing a million samples, you gain a factor of a thousand in
signal to noise ratio. Just as with Paul Kocher's timing attacks, merely
adding noise to the signal (i.e. random delays) does not protect against
the attack.

   Thanks to Eric Hughes for many of the ideas presented here.

   The second attack uses reliability information. This attack is
devastating against anonymous servers, much more so than anonymous
browsers. However, in the Web today, the distinction between servers and
browsers is not airtight. I'll describe the attack for servers first and
then touch on how to make browsers act as servers.

   The assumption for this attack against servers is that the adversary
has access to reliability information for both the physical nodes and
the pseudonymous servers. This assumption is quite reasonable.
Reliability information for the pseudonymous servers must be public
information, because either you can access the page or you can't. In
addition, onion routing forces the reliability information of physical
nodes to be public information, otherwise it would be impossible to
build onions that had a high probability of working. (experience with
the remailer list highlights this fact - even with fairly decent
statistics gathering, and with all information fully public, the
reliability of chains of 5 remailers is usually no higher than 90-95% -
see http://kiwi.cs.berkeley.edu/remailer-chains for the current stats)

   Again, traffic analysis is performed by correlating the reliability
info for the physical and pseudonymous servers. It's possible to do even
better than plain correlation, though, because if the physical server is
down, the corresponding pseudonymous server _must_ also be down. Thus,
when a physical server goes down, the list of pseudonymous servers that
are still up can be excluded from the possibile pseudonymous server
associated with that physical server. If this exclusion process narrows
down the list of possible servers to one, then that's much stronger
evidence than merely a high correlation.

   This particular type of analysis makes it particularly difficult to
overwhelm the signal with noise. If the servers are quite unreliable,
then there's lots of signal to analyze. On the other hand, by making the
servers very reliable, you also eliminate the noise. If only one server
is down at any given time, it becomes trivial to analyze them. Thus, I
consider this attack to be among the most fruitful when it is feasible.

   Now, how to generalize this attack to browsing? One easy way I can
think of is to apply the same Java applet technique, only this time
geared to detecting sudden disruptions. For example, the applet could
cause the browser to reload a small HTML file periodically, functioning
as a watchdog. To distinguish server failures from people getting bored
with the page they're watching, the applet sends a message to the server
when it terminates normally.

   Thus, whenever a physical server goes down, the applet's server looks
for the watchdog sequences to suddenly cease. If these are fairly rare
events, and if there are many simultaneous connections, it would count
as strong evidence.

   I can envision somewhat less effective passive attacks too, for
example based on Markov models of typical browsing behavior. Again, if
typical browsing behavior can be distinguished from sudden disruptions
of service, that's all the leverage needed for traffic analysis.

   Many of these ideas in this second attack are due to Lewis McCarthy.

   Now for some discussion of constant bandwidth. As I see it, the main
idea of constant bandwidth is to make it impossible, by definition, to
distinguish between different patterns of traffic. To extend the random
number analogy, they are the analog of truly random numbers (i.e. a flat
distribution of probabilities) as opposed to pseudorandom numbers (i.e.
a highly uneven distribution, but hopefully one which cannot be
distinguished from a flat one). The analogy to Paul Kocher's timing
attacks is again instructive.

   The distinguishability criterion is helpful, I believe. As long as
the signal is made indistinguishable on some level (for example, calling
write() on the socket at a constant rate, with a constant number of
bytes), it doesn't matter if there are variations on other levels (for
example, IP variability). Thus, I think that the discussion of needing
IPv6 or ATM is moot.

   To address some of the points that Michael made about "us vs. them,"
I'm very happy to see the NRL doing this research. I have no doubt that
you guys have what it takes to pull this project off. I'm also happy to
see that your goal is to resist serious traffic analysis (as opposed to
hiding browsing patterns from your little sister). We cypherpunks have
been thinking about these problems for quite some time, as they are
central to our agenda, but too often we sit around and talk about them
rather than actually building things.

   However, it seems clear that the problem of building an anonymous
network strongly resistant to traffic analysis is _hard,_ quite a bit
harder than your Oakland paper draft seems to credit. If you're going to
make the claim that the system you build is resistant in this way, then
you'll also have to show how it holds up against very best attacks that
can be mounted, not just the straightforward marker tracking attack as
described in section 6 of the Oakland draft.

   As promised, finally an invitation. I think it would be great if the
onion routing people could get together with a group of cypherpunks who
have put some thought into this problem. Since the onion routing people
will be in the Bay Area for Oakland, and since most of the relevant
cypherpunks live here (with Lewis McCarthy being the most notable
exception), I'd like to organize a dinner at my apartment sometime
during the Oakland conference. I live about six blocks from the
Claremont hotel where the conference is held, and I'm willing to try
some onion recipes. I think this would really give us the chance to talk
seriously about network anonymity, and get to know each other better.

   I've got to get back to writing my paper now. I probably won't have
time in the next couple of weeks to respond to followups, but hope to be
able to do so after I get back from out of town.

Raph

P.S. One correction to the Oakland draft. The discussion of anonymous
reply mail in section 9 seems to me to be inaccurate. The nymservers
implement an "encrypted reply block" which seems to me to be fully
analogous to reply onions. In this model, the nymserver functions as the
"client proxy", mapping human-readable e-mail addresses to encrypted
reply blocks, while the other remailers in the chain simply forward and
encrypt the mail statelessly. Under the assumption that passing through
a remailer really hides the connection (i.e. discounting the traffic
correlation attacks outlined above), it suffices that a single remailer
be uncompromised to protect the traffic.
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	id AA11284; Wed, 12 Mar 97 15:46:15 EST
Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA11278; Wed, 12 Mar 97 15:46:09 EST
From: syverson@itd.nrl.navy.mil (Paul Syverson)
Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id PAA10646 for onions@itd.nrl.navy.mil; Wed, 12 Mar 1997 15:46:05 -0500 (EST)
Date: Wed, 12 Mar 1997 15:46:05 -0500 (EST)
Message-Id: <199703122046.PAA10646@carnap.itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: A quick observation on terminology
X-Sun-Charset: US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


I've noticed that many postings treat `traffic analysis' as including
(at least) confirming that Alice and Bob are communicating given that
one specifically targets them as potential communicants. If this is
standard terminology, so be it. If it's not set in stone, however, I
think this should be called something like traffic pattern
confirmation.  Analysis is determining who is talking to whom (or who
is Alice talking to, or who is talking to Bob).  Compare
`cryptanalysis', which usually does not include confirming correct
guesses of keys or discovering keys by exhaustively rejecting bad
guesses.  Traffic analysis (sensu stricto) and traffic pattern
confirmation may both be important to guard against, but they are
distinct threats.

aloha,
Paul

P.S. Email may be the most efficient mechanism ever devised for creating
offense where none was intended. If we start telling each other how
smart (or dumb) we are, things will probably quickly degenerate to...
well, to the usual level of email discussions.

Sincerely,
Paul Syverson
Floral Park-Bellerose (Elementary) School
Class of 1970

From majordom  Wed Mar 12 17:20:10 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16071; Wed, 12 Mar 97 17:20:10 EST
Received: from ccnet4.ccnet.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16037; Wed, 12 Mar 97 17:19:56 EST
Received: from sfbayarea.ccnet.com (h108-14-159.ccnet.com [199.108.14.159]) by ccnet4.ccnet.com (8.7.1/8.6.12) with SMTP id OAA07020 for <onions@itd.nrl.navy.mil>; Wed, 12 Mar 1997 14:21:04 -0800 (PST)
Message-Id: <3.0.32.19970312132106.006e1adc@netcom9.netcom.com>
X-Sender: shamrock@netcom9.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 12 Mar 1997 14:21:03 -0800
To: Onion Routing List <onions@itd.nrl.navy.mil>
From: Lucky Green <shamrock@netcom.com>
Subject: Re: Bandwidth/Padding/etc...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 08:59 AM 3/12/97 -0500, Michael G. Reed wrote:
>	If we do "data smoothing", we can fluctuate bandwidth with
>available capacity of the Internet.  I'm not talking real short term
>smoothing, but prolonged smoothing where we change individual link
>utilization over time with regard to how much traffic we are sending,
>and how much traffic exists on the physical links outside of our
>system.  I think data smoothing offers a more robust system than just
>enforcing a hard capacity since that hard capacity would have to be
>based on the slowest, most unreliable link in the system.

The idea of "smoothing" has merit. When it was first mentioned, I thought
you were talking about a high frequency smoothing. But if you mean by
smoothing a low frequency smoothing, say adding and removing available
bandwidth along well established daily usage patterns, then smoothing may
not provide the attacker with more information than a constant bandwidth
pipe would.

>	What it all really comes down to is what our threat model is,
>and what we can do on the existing Internet.  I think it is
>unreasonable to wait for IPv6, or to say we will only deploy on ATM
>clouds.  Furthermore, I think it is unreasonable to enforce
>artifically low link capacities because of one bad link somewhere.  I
>urge people to comment on all of this.

Agreed. It all comes down to the treat model. I assume a very resourceful
adversary that can monitor the entire network, or at least large parts of
it. The adversary in my threat model also can conduct active attacks. What
is your threat model?

As to the link capacity, I believe the core routers should be on high
capacity links that can be assumed to be mostly stable. The link between a
core router and the user's proxy must of course be assumed to be unstable.



-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Wed Mar 12 17:20:14 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16082; Wed, 12 Mar 97 17:20:14 EST
Received: from ccnet4.ccnet.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16043; Wed, 12 Mar 97 17:19:59 EST
Received: from sfbayarea.ccnet.com (h108-14-159.ccnet.com [199.108.14.159]) by ccnet4.ccnet.com (8.7.1/8.6.12) with SMTP id OAA07025; Wed, 12 Mar 1997 14:21:06 -0800 (PST)
Message-Id: <3.0.32.19970312142049.00710208@netcom9.netcom.com>
X-Sender: shamrock@netcom9.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 12 Mar 1997 14:21:04 -0800
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>, onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: Re: discussion points
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 07:45 AM 3/12/97 -0500, Michael G. Reed wrote:
>If this is the assumption, then everything is a moot point.  If some
>adversary operates all but one core onion router he KNOWS with 100%
>certainty where the connection originated though.

Not necessarily. Assume for a moment the uncompromised router is the node a
user's proxy connects into. The attacker knows all incoming plaintext data
for all the users who connect to the uncompromised node. Depending on how
many users connect to that node, and how many of them keep the connection
up most of the time, the attacker may or may not be able to determine the
ultimate browser.

>|>>As another example, if two sites connect (encrypted) to remote onion
>|>>routers at roughly the same time, it is more likely that they are
>|>>communicating than if they didn't connect at roughly the same time.
>|>>This is hard to protect against.
>|>
>|>That's where constant bandwidth _will_ make the difference.
>
>No, constant bandwidth makes absolutely NO difference in this
>situation.  This is an attack which looks at coincidences of NEW
>connections going IN TO and OUT OF the network...not data flow within
>the network, but timing on new connections.  Bandwidth means nothing
>here.

Upon re-reading your original post, I agree that constant bandwidth amongst
the routers will not help against a passive attacker in this case. What
will help, however, is constant bandwidth between the user's proxy and the
first core router. If the user makes a connection to an onion router in the
morning and leaves it up until the evening, the passive attacker learns
nothing. Other than your work hours, that is :-)

[about noise]
>This can be done a number of ways including: 1) letting the higher
>level protocol do it, 2) Inserting it into DATA cells somehow
>(possibly by having cells with illegal lengths...only the last router
>would be able to determine this, which might, in turn, give you some
>more information to attack the connection), or 3) Adding a new cell
>type (BAD idea since it introduces markers that can be tracked
>independent of the other cell types).  To somewhat quote Monte Python,
>"#3 is right-out".  Furthermore, I really have to think some more
>about #2 before I would consider adding it.  #1 is by far the best,
>but we are trying to coexist with UNMODIFIED internet applications, so
>this is difficult.

Of course you want to interoperate with unmodified Internet applications.
That's why you should use a client side proxy. What happens at the other
side of the proxy is yours to choose. It could be as simple as a steam
cipher into which the proxy xor's the data. [Client side proxies are the
future. My thanks go to Jim McCoy for convincing me of that. In fact, the
average user's machine will probably run multiple chained proxies for the
same protocol:

An onion routing proxy to access the network, followed by SafePassage to
increase SSL strength from 40 to 128 bit, followed by a decrypting proxy
for webpages that are stored encrypted, followed by CookieCutter, to get
rid of unwanted cookies, etc. That's four chained proxies for HTTP alone.
[As a side bar, proxies@communities.com is the list where we are currently
discussing specs for a "universal" client side proxy that allows for
dynamic loading of proxy modules.]

>|>>Do we want padding between neighboring onion routers?
>|>
>|>Sure.
>
>Inter-node padding does not solve the problem of "bad" nodes.

Agreed.

>It will
>help confound external observers, but a bad node will always know what
>is padding on node to node padding.  End to end padding could be
>hidden from all but the last node, 

It might help to think of the "last node" as something that resides on the
user's machine.

>and protocol padding could be
>hidden from all nodes.

Wouldn't that require a proxy on the accessed website?

>|>I don't know anybody that has longer and deeper thought about these issues
>|>than the subscribers to this list. Onion routing  is a good idea. It just
>|>needs to take some other research into account.
>
>Research or practical experience?  We are researchers.  That is our
>job description.  That is what we get paid to do.  There are more
>PhD's walking around this base than some college campuses.  We publish
>constantly in academic circles, we attend conferences, we participate
>in the larger academic world.  Please do not assume that since we work
>for the government that we are uninformed, undereducated, GAK-loving
>idiots.

The mere fact that you are working on Onion Routers proves that you have a
clue and are none of the things that you seem I am assuming. I assure you,
I am not assuming any of the traits you mention.

>  What we lack is the practical experience in this area -- most
>of what we do is theory, theory, theory...very little applied (at
>least in the computer security area).  Thus the prototype where we've
>already learned a great deal about where the theoretical models break
>down in the real world.  Thus all the discussions with people running
>other MIX variants in the world (both in research labs and actually
>out there on the Internet).  Thus the need for a wider participation
>and the push for a general RFC that can be accepted by the whole
>Internet community.  Please don't view this as an "us vs. them"
>environment...we want the same level (and possibly even higher level)
>of security that you want out of this system...help us do that.

Which is exactly the reason why I am talking with you, published your URL
to the relevant mailing lists, and convinced people I knew to be
knowledgable about this topic to subscribe to this list.

This is not an "us vs. them" for any person on the list that I know. And I
probably know most, if not all subscribers (other than the one's from NRL,
whom I first met at FC'97).

Most of the non-NRL subscribers on this list are, or have been, subscribers
to the Cypherpunks mailing list. The overriding goal was to secure the
communications infrastructure and achieve privacy by preventing the
adversary from gaining information about an individual or corporation by
being able to read or traffic analyze the communications. Classical COMSEC.

The old Cypherpunks and the US Navy are facing the same problem and are
therefore looking at similar solutions. You need broad public use of the
system to provide you with cover traffic and we want to see such a system
deployed to provide the citizens with privacy. We are allies, not enemies. 

It is in this spirit of cooperation that we are pointing out issues with
your design that some of us believe require fixing before the system can
achieve our common goal. We all want to see the best design possible to be
deployed, because we all know that no other design will ever achieve the
broad penetration that we seek. Let's all work together on making that
design a reality.

Thanks,




-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Thu Mar 13 08:02:54 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA06969; Thu, 13 Mar 97 08:02:54 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA06959; Thu, 13 Mar 97 08:02:42 EST
Date: Thu, 13 Mar 1997 08:02:52 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: [LONG] Re: Asymmetric routes
In-Reply-To: <33271F49.595B884E@veriweb.com>
Message-Id: <Pine.GSO.3.95.970313080006.7777E-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 12 Mar 1997, Jeremey Barrett wrote:
|>Another possible implementation would be for the initiator to supply
|>"prebuilt" DATAHDRs to the responder. Then the initiator would only
|>need to supply one crytpo operation/key to the responder. The responder
|>can still tell the length of the return route from the size of the
|>DATAHDRs it gets, but does not have the keys to encrypt. Actually,
|>the initiator could fool the responder and append several bogus DATAHDRs
|>if necessary, eliminating even that possibility. The overhead is
|>getting ugly here, given 44-byte messages.

This looks like it would work, and as long as you didn't need to do it
too frequently the overhead may be acceptible.  Given the level of
complication we've just described in the last few messages, I'm
reluctant to jump to impliment this though...I'm not entirely sure how
much power we gain from this change or how much better this defeats
our threat model.  Looks like it gives us a lot more robustness
against node failure, but I'm not sure what else it gives us.

- -Michael


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMyf7AE8Qx019l0ClAQFIzwP9FwaIKhZ5UP/517UoZ6Rl6SzyJUbEKpUY
D6TpI1C4co1yKlF9MO3MM4oOjGPzadXS2QzznnRQ3pvtZRtUdxGuTSywRXQ0M7mL
qQ690MfxWvlGZwQOOrD6mUOks9mBCEz0KOMjXQyxTB7sudh+TNL1PGfg3PUel++v
UVbm8EPDMTI=
=3vid
-----END PGP SIGNATURE-----


From majordom  Thu Mar 13 08:20:16 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA07754; Thu, 13 Mar 97 08:20:16 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA07742; Thu, 13 Mar 97 08:20:06 EST
Date: Thu, 13 Mar 1997 08:20:15 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: discussion points
In-Reply-To: <3.0.32.19970312142049.00710208@netcom9.netcom.com>
Message-Id: <Pine.GSO.3.95.970313080433.7777F-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 12 Mar 1997, Lucky Green wrote:
|>>No, constant bandwidth makes absolutely NO difference in this
|>>situation.  This is an attack which looks at coincidences of NEW
|>>connections going IN TO and OUT OF the network...not data flow within
|>>the network, but timing on new connections.  Bandwidth means nothing
|>>here.
|>
|>Upon re-reading your original post, I agree that constant bandwidth amongst
|>the routers will not help against a passive attacker in this case. What
|>will help, however, is constant bandwidth between the user's proxy and the
|>first core router. If the user makes a connection to an onion router in the
|>morning and leaves it up until the evening, the passive attacker learns
|>nothing. Other than your work hours, that is :-)

True.  This would be a slightly different implementation than we
currently have since every connection to a proxy generates a new
connection into a core onion router (ie, unless the protocol allows
for sequencing request over one socket, you have N sockets for N
requests...HTTP 1.1 allows for this).  This design is different than
our original design (oh, about 9 months ago) where proxy and core were
one process, and some of our testing to date has pointed out that it
was (probably) a mistake to make this division (the division was made
since the fundamental core architecture is not application specific,
so people could write new proxies and have them talk to the network
without having to replace core onion routers...only add the proxy --
while nice from a theoretical perspective, every time we go up and
down the IP stack (even on the same machine) and have more system
calls, our efficiency goes down.  We may ultimately roll the well
established proxies into the core onion routers and still allow for
new (experimental) proxies to connect as they do now.  Comments?

|>[about noise]
|>>This can be done a number of ways including: 1) letting the higher
|>>level protocol do it, 2) Inserting it into DATA cells somehow
|>>(possibly by having cells with illegal lengths...only the last router
|>>would be able to determine this, which might, in turn, give you some
|>>more information to attack the connection), or 3) Adding a new cell
|>>type (BAD idea since it introduces markers that can be tracked
|>>independent of the other cell types).  To somewhat quote Monte Python,
|>>"#3 is right-out".  Furthermore, I really have to think some more
|>>about #2 before I would consider adding it.  #1 is by far the best,
|>>but we are trying to coexist with UNMODIFIED internet applications, so
|>>this is difficult.
|>
|>Of course you want to interoperate with unmodified Internet applications.
|>That's why you should use a client side proxy. What happens at the other
|>side of the proxy is yours to choose. It could be as simple as a steam
|>cipher into which the proxy xor's the data. [Client side proxies are the
|>future. My thanks go to Jim McCoy for convincing me of that. In fact, the
|>average user's machine will probably run multiple chained proxies for the
|>same protocol:
|>
|>An onion routing proxy to access the network, followed by SafePassage to
|>increase SSL strength from 40 to 128 bit, followed by a decrypting proxy
|>for webpages that are stored encrypted, followed by CookieCutter, to get
|>rid of unwanted cookies, etc. That's four chained proxies for HTTP alone.
|>[As a side bar, proxies@communities.com is the list where we are currently
|>discussing specs for a "universal" client side proxy that allows for
|>dynamic loading of proxy modules.]

Great idea, but isn't that going to be a little heavy on the overhead?
Also, how are you handling the parsing/tokenizing of HTML?  Right now
it looks like our anonymizing proxies does some of these all wrapped
up in one (cleans up the data stream, routes through onion routing,
and certainly we could add end to end crypto like stronger SSL).

|>>It will
|>>help confound external observers, but a bad node will always know what
|>>is padding on node to node padding.  End to end padding could be
|>>hidden from all but the last node, 
|>
|>It might help to think of the "last node" as something that resides on the
|>user's machine.

I was thinking more in terms of the other end of the pipe (ie, the end
away from the user would know it had got padding).

|>>and protocol padding could be
|>>hidden from all nodes.
|>
|>Wouldn't that require a proxy on the accessed website?

Not necessarily.  It could just make bogus requests to that website.
The last node will not be able to determine a valid request from a
bogus request since they are both legitimate....we're just ignoring
the response of the later when it get's back to the original
requestor.

|>The mere fact that you are working on Onion Routers proves that you have a
|>clue and are none of the things that you seem I am assuming. I assure you,
|>I am not assuming any of the traits you mention.

Great! :-) Really though, I was just venting at no one in
particular...  most of the email that had stroked me the wrong way was
from people that are not on the list and really don't want to bother
being on the list because they don't want to help/contribute but are
VERY quick to jump to conclusions and criticize something they don't
understand.  We *REALLY* do appreciate all the comments we've gotten
from the list in the past week or so here (for one thing, it has
fundamentally shaken a few of us with regard to some of our base
assumptions about the threat model...), keep them coming :-)


- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMyf/FE8Qx019l0ClAQHP0QP6A6fc8Kx5X/SZ2nYOU0Gbs97aMgxEHuuw
0mF3dXVvWi0VeelW6CrUwdnCnam2Y8qWXfRCUh2JgqWj9QBdIXxhehO3ZG/cc3IG
GXNgHfd3Himb0YLwvqv4TaONrEggHJJzSQDqoGNkN9mQZ5W4VXV8o9bfHYvvymUp
soBTNiHMAg8=
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-----END PGP SIGNATURE-----


From majordom  Thu Mar 13 08:33:12 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA08325; Thu, 13 Mar 97 08:33:12 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA08302; Thu, 13 Mar 97 08:32:59 EST
Date: Thu, 13 Mar 1997 08:33:08 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Bandwidth/Padding/etc...
In-Reply-To: <3.0.32.19970312132106.006e1adc@netcom9.netcom.com>
Message-Id: <Pine.GSO.3.95.970313082726.7777H-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 12 Mar 1997, Lucky Green wrote:
|>The idea of "smoothing" has merit. When it was first mentioned, I thought
|>you were talking about a high frequency smoothing. But if you mean by
|>smoothing a low frequency smoothing, say adding and removing available
|>bandwidth along well established daily usage patterns, then smoothing may
|>not provide the attacker with more information than a constant bandwidth
|>pipe would.

Yes, lower frequency is what I had envisioned...it could even done at
different levels (ie, general bandwidth could follow one pattern per
24x7 usage and then we could allow for some deviations in time if
really high usage...essentially allow us to push the threshold up a
little more if we really need it and then gradually fall back down to
the 24x7 rolling threshold).

|>Agreed. It all comes down to the treat model. I assume a very resourceful
|>adversary that can monitor the entire network, or at least large parts of
|>it. The adversary in my threat model also can conduct active attacks. What
|>is your threat model?

I believe David is currently writing up our threat model (Aren't you
Dave :-), so it should be out there soon.

|>As to the link capacity, I believe the core routers should be on high
|>capacity links that can be assumed to be mostly stable. The link between a
|>core router and the user's proxy must of course be assumed to be unstable.

I like the sound of that, but I'm wondering if we really can get the
high-bandwidth/stable/geographically and locally diverse requirements
met for core routers.  Also, what do we do if joe-down-the-street is
hanging off a 128k ISDN link but wants to run a core router...do we
say no?

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMygCGE8Qx019l0ClAQHuRgP/RwPRkfSFgExhhfs5NZkukHfc5Wi8VRZN
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-----END PGP SIGNATURE-----


From majordom  Wed Mar 26 02:53:11 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10967; Wed, 26 Mar 97 02:53:11 EST
Received: from netcom13.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10961; Wed, 26 Mar 97 02:53:03 EST
Received: from sfbayarea.ccnet.com (h108-14-160.ccnet.com [199.108.14.160]) by netcom13.netcom.com (8.6.13/Netcom)
	id XAA10506; Tue, 25 Mar 1997 23:52:59 -0800
Message-Id: <3.0.32.19970325235326.0073e2c0@netcom9.netcom.com>
X-Sender: shamrock@netcom9.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 25 Mar 1997 23:53:37 -0800
To: <onions@itd.nrl.navy.mil>
From: Lucky Green <shamrock@netcom.com>
Subject: Threat model?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Folks,
It has been rather silent on this list. Did NRL finish the threat model?
Dave? I'd love to see it and I am sure so would others on the list.

And we are all still waiting for the source code...

Thanks,


-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Wed Mar 26 09:06:40 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA19944; Wed, 26 Mar 97 09:06:40 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA19938; Wed, 26 Mar 97 09:06:32 EST
Date: Wed, 26 Mar 1997 09:06:40 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Threat model?
In-Reply-To: <3.0.32.19970325235326.0073e2c0@netcom9.netcom.com>
Message-Id: <Pine.GSO.3.95.970326090319.1167A-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 25 Mar 1997, Lucky Green wrote:
|>It has been rather silent on this list. Did NRL finish the threat model?
|>Dave? I'd love to see it and I am sure so would others on the list.

That's Dave's ballpark...

|>And we are all still waiting for the source code...

I've been working fast and furious to get the code ready for
distribution...there were a few things that really needed to be
cleaned up and fixed up before people start trying to run one of these
things themselves (like the configuration files where you had to
specify the onion routers in network order hexadecimal since I hadn't
bothered with DNS resolution on them :-) I'm doing the last round of
integration testing with our STS crypto code and generating some DH
keys (unlike the RSA keys which I can generate in a few seconds on my
machines, the DH keys take anywhere from 3 to 12 hours to generate
with BSAFE).  I hope to have it ready by tomorrow, but Friday or early
next week is looking more likely.  More info to follow...

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzktdE8Qx019l0ClAQEE7wP/Wse05Y3IT+T1YBeRPMmA1in+G8hs+0LO
keiaRacLW+t3PBWNIAhWnfM6KfB2Xqk1fu75v+yc7Q4bhJlVH8T6FgMUJcBJXv+5
zDMFvyCae3L9EnKqTmevRswMY/5G2d33WqmqlAxFZEZqYkmYox9mmB2h6oXwK03J
3RZoe/51n2I=
=uBLy
-----END PGP SIGNATURE-----


From majordom  Thu Mar 27 00:47:19 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA22812; Thu, 27 Mar 97 00:47:19 EST
Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA22804; Thu, 27 Mar 97 00:47:07 EST
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id AAA18274 for <onions@itd.nrl.navy.mil>; Thu, 27 Mar 1997 00:46:52 -0500
Message-Id: <333A09CC.446B@cs.umass.edu>
Date: Thu, 27 Mar 1997 00:46:52 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
Mime-Version: 1.0
To: Onion Routing Mailing List <onions@itd.nrl.navy.mil>
Subject: Dolev talk at MIT on "Efficient Anonymous Multicast and Reception"
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

I gather this talk is scheduled for Mon. Apr. 14. I don't know any
room/time details; they may be still TBA.

Be Blackburn writes:
[...]
> Date: Sun, 23 Mar 1997 10:41:17 +0300 (IDT)
> From: Shlomi Dolev <dolev@CS.bgu.ac.il>
> To: Ron Rivest <rivest@theory.lcs.mit.edu>
> Subject: Re: talk
[...]
> The title:
> 
> Efficient Anonymous Multicast and Reception
> 
> The speaker (me):
> Shlomi Dolev
> Department of Math. and Computer Science
> Ben-Gurion University
> 
> The abstract:
> 
> We examine the problem of efficient anonymous broadcast
> and reception in general communication networks.  We show how
> anonymous broadcast/reception can be achieved with $O(1)$ amortized
> communication complexity per bit sent and low computational
> complexity. In contrast, all previous solutions required polynomial
> (in the size of the network and security parameter) communication
> complexity. Joint work with Rafail Ostrovsky.
[...]

-- 
Lewis    http://www.cs.umass.edu/~lmccarth/lmkey.asc   "And all the 
science, I don't understand; it's just my job, eight days a week..."

From majordom  Fri Mar 28 12:24:16 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA02166; Fri, 28 Mar 97 12:24:16 EST
Received: from netcom13.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA02152; Fri, 28 Mar 97 12:24:08 EST
Received: from sfbayarea.ccnet.com (h96-132.ccnet.com [192.215.96.132]) by netcom13.netcom.com (8.6.13/Netcom)
	id JAA09160; Fri, 28 Mar 1997 09:24:04 -0800
Message-Id: <3.0.32.19970328092341.006fffbc@netcom9.netcom.com>
X-Sender: shamrock@netcom9.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 09:24:19 -0800
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>,
        Onion Routing List <onions@itd.nrl.navy.mil>
From: Lucky Green <shamrock@netcom.com>
Subject: Re: Threat model?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 09:06 AM 3/26/97 -0500, Michael G. Reed wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>On Tue, 25 Mar 1997, Lucky Green wrote:
>|>It has been rather silent on this list. Did NRL finish the threat model?
>|>Dave? I'd love to see it and I am sure so would others on the list.
>
>That's Dave's ballpark...

Is Dave reading this list?  [Hi, Dave :-] If so, when do you expect the
thread model to be done? I don't want to rush you. I just would like to
know the ETA. Thanks!

>|>And we are all still waiting for the source code...
>
>I've been working fast and furious to get the code ready for
>distribution...there were a few things that really needed to be
>cleaned up and fixed up before people start trying to run one of these
>things themselves (like the configuration files where you had to
>specify the onion routers in network order hexadecimal since I hadn't
>bothered with DNS resolution on them :-)

I hear you.

> I'm doing the last round of
>integration testing with our STS crypto code and generating some DH
>keys (unlike the RSA keys which I can generate in a few seconds on my
>machines, the DH keys take anywhere from 3 to 12 hours to generate
>with BSAFE).  I hope to have it ready by tomorrow, but Friday or early
>next week is looking more likely.  More info to follow...

Why are you using BSAFE? You are a research institution. You aren't
required to use RSA's software implementation. You can use more efficient
software. Not to mention hardware. Lately, I have been working with the
Rainbow PCI boards. According to some very preliminary testing, they are
worthy of our attention. Let me know if you'd like a contact there for some
samples.

Thanks,


-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Fri Mar 28 12:34:17 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA02590; Fri, 28 Mar 97 12:34:17 EST
Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA02584; Fri, 28 Mar 97 12:34:12 EST
Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id MAA08889; Fri, 28 Mar 1997 12:34:09 -0500 (EST)
Date: Fri, 28 Mar 1997 12:34:09 -0500 (EST)
Message-Id: <199703281734.MAA08889@golem.itd.nrl.navy.mil>
From: David Goldschlag <goldschl@itd.nrl.navy.mil>
To: shamrock@netcom.com
Cc: onions@itd.nrl.navy.mil
In-Reply-To: <3.0.32.19970328092341.006fffbc@netcom9.netcom.com> (message from
	Lucky Green on Fri, 28 Mar 1997 09:24:19 -0800)
Subject: BSAFE
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


We don't have any particular affinity for BSAFE.  We are using it
because it was available, well documented, and comprehensive, and
thread safe.

We have written our code so other crypto packages can be substituted
in for BSAFE.

We would be very interested in learning about hardware implementations
of RSA and symmetric crypto for Suns and other platforms that do not
require much overhead to re-key.  Since each onion router runs many
connections at a time it has to switch between crypto engines
constantly.  BSAFE functions are stateless, so this is easy.

David.

From majordom  Fri Mar 28 12:36:48 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA02722; Fri, 28 Mar 97 12:36:48 EST
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA02716; Fri, 28 Mar 97 12:36:42 EST
Date: Fri, 28 Mar 1997 12:36:52 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Threat model?
In-Reply-To: <3.0.32.19970328092341.006fffbc@netcom9.netcom.com>
Message-Id: <Pine.GSO.3.95.970328122549.9219E-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 28 Mar 1997, Lucky Green wrote:
|>> I'm doing the last round of
|>>integration testing with our STS crypto code and generating some DH
|>>keys (unlike the RSA keys which I can generate in a few seconds on my
|>>machines, the DH keys take anywhere from 3 to 12 hours to generate
|>>with BSAFE).  I hope to have it ready by tomorrow, but Friday or early
|>>next week is looking more likely.  More info to follow...
|>
|>Why are you using BSAFE? You are a research institution. You aren't
|>required to use RSA's software implementation. You can use more efficient
|>software. Not to mention hardware. Lately, I have been working with the
|>Rainbow PCI boards. According to some very preliminary testing, they are
|>worthy of our attention. Let me know if you'd like a contact there for some
|>samples.

We're using BSAFE for a couple of reasons: 1) it was essentially free
to us, 2) we know it works, 3) we get great support, 4) I was too lazy
to code up the crypto myself, and 5) up until recently, this was just
a proof-of-concept project, so performance wasn't an issue.  As for
other crypto, we have a fast version of RSA for the Ultrasparc 2
(sparc v9 architecture) that was coded in assembly for us by a
contractor.  It's a LOT faster than BSAFE, so we use it for the onion
encryption/decryption, but not for STS (this is a side technical issue
that really doesn't matter at this point) -- downside is that it
requires an Ultra2 (not a problem for us, but could be a kink for
others :-).  Hardware support would be nice, but we really don't
envision many people having access to SBUS crypto boards (the prices
are astronomical when we looked into it).  We haven't really looked at
PCI cards since you can't just slap one into a sparc (this will become
a more viable option once we've ported to other platforms that have a
native PCI bus) without other additional hardware.  I'd be interested
in any timing figures you have on hardware RSA and hardware DES (of
course, we can move away from DES...the system allows for any
symmetric stream cryptosystem with up to 128-bits of key) -- we know
that a big bottleneck in the system now is the crypto (about 1MB/sec
on DES on an Ultra2, and a HELL of a lot lower for RSA).  Thanks.

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzwBuE8Qx019l0ClAQHPkwP/XrOeZWDdicYzRg9rREkNB2zczj2aDA+P
5v6OY/NMNPYw8Y2kBsdP68KxReGbyz5vdtTe1yM+QI+/YCqFh5OQp86B0mmSKeQ+
CxkV2vagnkEp0taPrmHTfA1Hx7Rknkhp4GTuuRmlah0ZLzmBtAKRbYlgrQNLdgSy
wmDPGjAU27g=
=/nNC
-----END PGP SIGNATURE-----


From majordom  Mon Mar 31 15:24:10 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA00943; Mon, 31 Mar 97 15:24:10 EST
Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA00910; Mon, 31 Mar 97 15:24:00 EST
Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id PAA10892; Mon, 31 Mar 1997 15:23:57 -0500 (EST)
Date: Mon, 31 Mar 1997 15:23:57 -0500 (EST)
Message-Id: <199703312023.PAA10892@golem.itd.nrl.navy.mil>
From: David Goldschlag <goldschl@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: beta test sites
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


Hi,

We're about ready to release onion routing binaries for limited test.
Testers will also get source.  The code runs under Solaris 2.x on Sun
Sparcs.  The system runs as root if you want to run the rlogin proxy.

To release any code, we need a signed license/non-disclosure
agreement.  I'm including an adequate one at the end.  This needs your
real name, address, and original signature.  Sorry.

The license/non-disclosure agreement does not limit who you may allow
to access the onion routing system.  It just limits redistribution of
both the binary and source code.

Also, since we will make the code (and future patches) available by
FTP, please attach to your letter the username/password that you want
to use, and the IP address of the machine that you will be ftp'ing
from.

Since configuration needs to be coordinated among the network, please
send me the following information also (by e-mail is fine):

What hardware you will be running onion routing on.

Name and IP address of the machine that will run onion routing.

Several port numbers on that machine:

We suggest the following standard ports:

9500 for connections from proxies.
9501 for connections from other onion routers.
9505 for debugging.

9000 for the HTTP proxy.
9200 for the anonymizing HTTP proxy.


Thanks,
David.

Here's an adequate license/non-disclosure letter, that Paul might
write, if he needed to and wanted to test the system.



From:
Paul Syverson
Naval Research Laboratory 
Washington, DC 20375-5337
(202) 767-2389
syverson@itd.nrl.navy.mil

To:
David Goldschlag
Naval Research Laboratory 
Center for High Assurance Computer Systems
Washington, DC 20375-5337
(202) 404-7310


Dear David:

I would like to run your onion routing system.  I am a US citizen, and
I agree not to redistribute the source or binary code, and to provide
reasonable protection against its unintended redistribution.

I understand that this license is valid only through the end of 1997,
and may be revoked earlier by the US government, and agree to destroy
my copies of the code at that time.


Yours truly,

(Paul's real signature here)


Paul Syverson


From majordom  Tue Apr  1 16:17:46 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA20789; Tue, 1 Apr 97 16:17:46 EST
Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA20781; Tue, 1 Apr 97 16:17:36 EST
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id QAA04226 for <onions@itd.nrl.navy.mil>; Tue, 1 Apr 1997 16:06:15 -0500
Message-Id: <33417B5D.ABD@cs.umass.edu>
Date: Tue, 01 Apr 1997 16:17:17 -0500
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
Mime-Version: 1.0
To: Onion Routing Mailing List <onions@itd.nrl.navy.mil>
Subject: [Fwd: Monday, Apr. 14th - TALK by Shlomi Dolev]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Here's the time & place of the upcoming talk at MIT I mentioned:

Be Blackburn wrote:
> 
> CRYPTOGRAPHY AND INFORMATION SECURITY GROUP SEMINAR
> 
> Date:  Monday, April 14
> Time:  4:00 p.m.
> Place: NE43-628, 6th floor conference room
> 
>     EFFICIENT ANONYMOUS MULTICAST AND RECEPTION
> 
>                  Shlomi Dolev
>     Department of Math. and Computer Science
>             Ben-Gurion University

Unfortunately I have to hold office hours on Monday evenings, so I
can't make it out to this. If someone else goes I'd be interested in
hearing about it.

-- 
Lewis    http://www.cs.umass.edu/~lmccarth/lmkey.asc   "And all the 
science, I don't understand; it's just my job, eight days a week..."

From majordom  Tue Apr  8 14:36:52 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA08136; Tue, 8 Apr 97 14:36:52 EDT
Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA08128; Tue, 8 Apr 97 14:36:44 EDT
Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id OAA22821; Tue, 8 Apr 1997 14:36:42 -0400 (EDT)
Date: Tue, 8 Apr 1997 14:36:42 -0400 (EDT)
Message-Id: <199704081836.OAA22821@golem.itd.nrl.navy.mil>
From: David Goldschlag <goldschl@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: dinner during Oakland
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


Hi,

Raph Levien suggested that people interested in onions get together
during Oakland.  I think that this is a great idea.

For the NRL crowd, Tuesday May 6th at about 7:30pm would be a good
time.  How does this sound for others?

Thanks,
David.


From majordom  Tue Apr  8 15:37:36 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA11062; Tue, 8 Apr 97 15:37:36 EDT
Received: from blacklodge.c2.net by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA11056; Tue, 8 Apr 97 15:37:28 EDT
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id MAA26550; Tue, 8 Apr 1997 12:37:14 -0700 (PDT)
Date: Tue, 8 Apr 1997 12:37:14 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: David Goldschlag <goldschl@itd.nrl.navy.mil>
Cc: onions@itd.nrl.navy.mil
Subject: Re: dinner during Oakland
In-Reply-To: <199704081836.OAA22821@golem.itd.nrl.navy.mil>
Message-Id: <Pine.BSF.3.91.970408122803.26281A-100000@blacklodge.c2.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk



On Tue, 8 Apr 1997, David Goldschlag wrote:

> 
> Hi,
> 
> Raph Levien suggested that people interested in onions get together
> during Oakland.  I think that this is a great idea.

I hope so too - I think it would be a great chance to meet and discuss 
the ideas further.

> For the NRL crowd, Tuesday May 6th at about 7:30pm would be a good
> time.  How does this sound for others?

It's not ideal for me. I've tentatively scheduled a dinner with someone
else for that evening. Also, since I was hoping to present one of the
5-minute talks, and also prepare the dinner, I wouldn't be able to do both
on that day. 

If that's the only day available, I can switch my other dinner, and we can
have our dinner at a restaurant on Tuesday. Otherwise, any of the other
days (from Saturday to Wednesday) would probably work out. I make a pretty
mean veggie lasagna and was planning to serve roasted onions as s side
dish, in keeping with the theme. My apartment is only six blocks from the
Claremont and would be a better place to spread out and talk than most
restaurants. 

So if you'd all let me know what days and times are available, I'll try 
to coordinate.

Raph

From majordom  Tue Apr  8 15:59:31 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA12471; Tue, 8 Apr 97 15:59:31 EDT
Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA12463; Tue, 8 Apr 97 15:59:23 EDT
Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id PAA22914; Tue, 8 Apr 1997 15:59:21 -0400 (EDT)
Date: Tue, 8 Apr 1997 15:59:21 -0400 (EDT)
Message-Id: <199704081959.PAA22914@golem.itd.nrl.navy.mil>
From: David Goldschlag <goldschl@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
In-Reply-To: <Pine.BSF.3.91.970408122803.26281A-100000@blacklodge.c2.net>
	(message from Raph Levien on Tue, 8 Apr 1997 12:37:14 -0700 (PDT))
Subject: Re: dinner during Oakland
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


It's always hard to coordinate a group.  Sunday night there is
probably a program committee meeting.  Monday night is the conference
reception, and people might leave by Wednesday. 

Does anyone else have a preference?

David.

From majordom  Tue Apr  8 16:56:48 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA15087; Tue, 8 Apr 97 16:56:48 EDT
Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA15081; Tue, 8 Apr 97 16:56:40 EDT
Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id NAA30922; Tue, 8 Apr 1997 13:59:15 -0700
Message-Id: <334AB197.3C59D86D@veriweb.com>
Date: Tue, 08 Apr 1997 13:59:03 -0700
From: Jeremey Barrett <jeremey@veriweb.com>
Organization: VeriWeb Internet Corp.
X-Mailer: Mozilla 3.01 (X11; U; Linux 2.0.11 i586)
To: David Goldschlag <goldschl@itd.nrl.navy.mil>
Cc: onions@itd.nrl.navy.mil
Subject: Re: dinner during Oakland
References: <199704081836.OAA22821@golem.itd.nrl.navy.mil>
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

David Goldschlag wrote:
> 
> Hi,
> 
> Raph Levien suggested that people interested in onions get together
> during Oakland.  I think that this is a great idea.

Agreed.

> 
> For the NRL crowd, Tuesday May 6th at about 7:30pm would be a good
> time.  How does this sound for others?
> 

Sounds fine, anytime is good for me.

Jeremey.
- -- 
Jeremey Barrett                                  VeriWeb Internet Corp.
Crypto, Ecash, Commerce Systems                 http://www.veriweb.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM0qxoy/fy+vkqMxNAQG2kgP8Cy6Cmdg+vxw3zS3EG4Uu5wUFcJOQkhBz
y1gHQzLubNhHhR72gnhvoUqwaawPFIuBCGv3/5Jv82EbThylLbb1RcPmD02YzABc
Sskb0edwnT0hXOQwlndRZARVDRWMDZRuM3MwPQn/IUtjdqd0cn0XYDnlIcqM49Ks
QUEflHdcH1Q=
=BMVt
-----END PGP SIGNATURE-----

From majordom  Tue Apr  8 17:33:34 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16424; Tue, 8 Apr 97 17:33:34 EDT
Received: from netcom19.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16418; Tue, 8 Apr 97 17:33:27 EDT
Received: from sfbayarea.ccnet.com (shamrock@netcom19.netcom.com [192.100.81.132]) by netcom19.netcom.com (8.6.13/Netcom)
	id OAA08821; Tue, 8 Apr 1997 14:33:22 -0700
Message-Id: <3.0.32.19970408142922.00741df8@netcom13.netcom.com>
X-Sender: shamrock@netcom13.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 08 Apr 1997 14:33:45 -0700
To: David Goldschlag <goldschl@itd.nrl.navy.mil>, onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: Re: dinner during Oakland
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 03:59 PM 4/8/97 -0400, David Goldschlag wrote:
>
>It's always hard to coordinate a group.  Sunday night there is
>probably a program committee meeting.  Monday night is the conference
>reception, and people might leave by Wednesday. 
>
>Does anyone else have a preference?

Any day will work for me.

Looking forward to an opportunity to discuss some ideas in more detail,



-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Tue Apr  8 18:23:33 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA17519; Tue, 8 Apr 97 18:23:33 EDT
Received: from homer.communities.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA17511; Tue, 8 Apr 97 18:23:27 EDT
Received: from [205.162.51.35] (pericles.communities.com [205.162.51.35]) by homer.communities.com (8.7.5/8.7.3) with ESMTP id RAA25231 for <onions@itd.nrl.navy.mil>; Tue, 8 Apr 1997 17:05:41 -0700
X-Sender: mccoy@mail.communities.com
Message-Id: <v03020903af70750a568f@[205.162.51.35]>
In-Reply-To: <3.0.32.19970408142922.00741df8@netcom13.netcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 8 Apr 1997 14:20:46 -0800
To: onions@itd.nrl.navy.mil
From: Jim McCoy <mccoy@communities.com>
Subject: Re: dinner during Oakland
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Lucky writes:
>At 03:59 PM 4/8/97 -0400, David Goldschlag wrote:
>>
>>It's always hard to coordinate a group.  Sunday night there is
>>probably a program committee meeting.  Monday night is the conference
>>reception, and people might leave by Wednesday.
>>
>>Does anyone else have a preference?
>
>Any day will work for me.

Ditto.

jim



From majordom  Wed Apr  9 16:27:07 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA23668; Wed, 9 Apr 97 16:27:07 EDT
Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA23644; Wed, 9 Apr 97 16:27:00 EDT
Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id QAA23564; Wed, 9 Apr 1997 16:26:57 -0400 (EDT)
Date: Wed, 9 Apr 1997 16:26:57 -0400 (EDT)
Message-Id: <199704092026.QAA23564@golem.itd.nrl.navy.mil>
From: David Goldschlag <goldschl@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: onions dinner
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


So Monday after the reception is probably OK also.

Raph, what do you prefer?  (We could meet at a restaurant for dinner
in either case, if that is easier.)

David.  

From majordom  Wed Apr  9 20:19:45 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA29502; Wed, 9 Apr 97 20:19:45 EDT
Received: from blacklodge.c2.net by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA29494; Wed, 9 Apr 97 20:19:37 EDT
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id RAA24287; Wed, 9 Apr 1997 17:19:35 -0700 (PDT)
Date: Wed, 9 Apr 1997 17:19:35 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: David Goldschlag <goldschl@itd.nrl.navy.mil>
Cc: onions@itd.nrl.navy.mil
Subject: Re: onions dinner
In-Reply-To: <199704092026.QAA23564@golem.itd.nrl.navy.mil>
Message-Id: <Pine.BSF.3.91.970409171809.21135B-100000@blacklodge.c2.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk



On Wed, 9 Apr 1997, David Goldschlag wrote:

> 
> So Monday after the reception is probably OK also.
> 
> Raph, what do you prefer?  (We could meet at a restaurant for dinner
> in either case, if that is easier.)

Monday after the reception is definitely better for me.

I'd still like to cook, unless I hear an overwhelming preference for a 
restaurant.

Raph


From majordom  Thu Apr 10 11:04:49 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA20435; Thu, 10 Apr 97 11:04:49 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA20421; Thu, 10 Apr 97 11:04:39 EDT
Date: Thu, 10 Apr 1997 11:04:48 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: New Onion Router on-line...
Message-Id: <Pine.GSO.3.95.970410105743.10659N-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

All-
	The newest code release (Beta1 -- what's going out to the
testers) of the onion-routing software is now on-line on
onion-router.nrl.navy.mil.  You will see some *BIG* performance
changes with this (for the worse mostly) since we are now doing:

	1) Full RSA and DES (this was turned off during earlier testing
	   phases so we could track packets for debugging).
	2) Full Mixing at 10microsecond intervals across all VCI's in
	   the system.

This hits hard on both latency and throughput of the system, but the
system appears to be robust under some of the most abusive conditions
we could generate.  Now that Beta1 is ready to go out, we are starting
to talk about Beta2...we've learned a *LOT* of important lessons from
Beta1 in terms of system throughput, latency, design, etc. and we plan
to completely re-engineer the design for Beta2.  I'll be sending out a
complete technical specification of what we did in Beta1 by early next
week, and more importantly, what we plan on doing for Beta2 (and why
we are changing the implementation so radically).  I would *REALLY*
like to see feedback on both the Beta1 design and the proposed Beta2
design since (as of right now) the idea is to use Beta1 to conduct
some tests, but build Beta2 "the right way" so it can actually be
deployed for full use on the Internet.  Comments?

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM00BlE8Qx019l0ClAQH6+wP/Wyi9ytJsY0Ke1JhJ8QPc2zzn2gugForb
WMlN+3ZPF9UbKRodlhhLtLCC4tva5cBcb8z/KCB3sZC4O/x62fksvuF/8nBFRw7K
KCDQLE7eo19+V3UWAnxBFWF7D6ual2y7izJKwDA2XvinFUh8o0ZgQwnMc/vVqqZJ
hQp+7lauqKE=
=eRrq
-----END PGP SIGNATURE-----


From majordom  Tue Apr 15 10:35:47 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA17088; Tue, 15 Apr 97 10:35:47 EDT
Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA17080; Tue, 15 Apr 97 10:35:34 EDT
Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id KAA26964; Tue, 15 Apr 1997 10:35:33 -0400 (EDT)
Date: Tue, 15 Apr 1997 10:35:33 -0400 (EDT)
Message-Id: <199704151435.KAA26964@golem.itd.nrl.navy.mil>
From: David Goldschlag <goldschl@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: Oakland Dinner
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


Hi,

So I propose that we meet at Raph's apartment after the reception on
Monday May 5th.

How does this sound?  Raph, can you please provide details?

Thanks,
David.

From majordom  Tue Apr 15 13:47:07 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA26749; Tue, 15 Apr 97 13:47:07 EDT
Received: from blacklodge.c2.net by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA26727; Tue, 15 Apr 97 13:46:56 EDT
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id KAA01885; Tue, 15 Apr 1997 10:46:34 -0700 (PDT)
Date: Tue, 15 Apr 1997 10:46:34 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: David Goldschlag <goldschl@itd.nrl.navy.mil>
Cc: onions@itd.nrl.navy.mil
Subject: Re: Oakland Dinner
In-Reply-To: <199704151435.KAA26964@golem.itd.nrl.navy.mil>
Message-Id: <Pine.BSF.3.91.970415103730.1253B-100000@blacklodge.c2.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk



On Tue, 15 Apr 1997, David Goldschlag wrote:

> 
> Hi,
> 
> So I propose that we meet at Raph's apartment after the reception on
> Monday May 5th.
> 
> How does this sound?  Raph, can you please provide details?

This sounds great to me. Here are the details:

My apartment is 345 62nd St. in Oakland. You just go down Claremont Ave
from the hotel, then take a gentle left onto 62nd at College (it's a
six-way intersection). We're in the big yellow house at the end of the
block (just before you get to Hillegass), on the left. It's about a 15 
minute walk, or you could drive.

I'm planning to prepare vegetarian lasagna, salad, and roasted onions. 
Plan on being there around 7:30. Dinner will be ready shortly thereafter. 

Please RSVP so I have some idea how much to cook.

Look forward to seeing you there!

Raph


From majordom  Thu Apr 17 17:42:10 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA21828; Thu, 17 Apr 97 17:42:10 EDT
Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA21811; Thu, 17 Apr 97 17:42:02 EDT
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246]) by freya.cs.umass.edu (8.7.6/8.6.9) with SMTP id RAA15799 for <onions@itd.nrl.navy.mil>; Thu, 17 Apr 1997 17:42:01 -0400
Message-Id: <33569928.41C6@cs.umass.edu>
Date: Thu, 17 Apr 1997 17:42:00 -0400
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: Theoretical Computer Science Group, UMass-Amherst, <http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
Mime-Version: 1.0
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: [Fwd: A new system for anonymity on the web]
Content-Type: message/news
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Path: kernighan.cs.umass.edu!umass.edu!cam-news-feed5.bbnplanet.com!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!newsxfer3.itd.umich.edu!news.eecs.umich.edu!quip.eecs.umich.edu!rubin
From: rubin@quip.eecs.umich.edu (Aviel Rubin)
Newsgroups: sci.crypt,alt.security
Subject: A new system for anonymity on the web
Date: 17 Apr 1997 13:46:57 GMT
Organization: University of Michigan, Ann Arbor, Michigan, USA
Message-ID: <5j59kh$pu6$1@news.eecs.umich.edu>
NNTP-Posting-Host: quip.eecs.umich.edu
Xref: kernighan.cs.umass.edu sci.crypt:59170 alt.security:27248

We are developing a new system called "Crowds" for achieving anonymity
on the web.  A preliminary description of the system can be found on
our web pages.  Any comments/criticisms are welcomed and appreciated.

Mike Reiter (http://www.research.att.com/~reiter/)
Avi Rubin   (http://www.research.att.com/~rubin/)



From majordom  Tue May  6 05:28:14 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10040; Tue, 6 May 97 05:28:14 EDT
Received: from netcom21.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10034; Tue, 6 May 97 05:28:06 EDT
Received: from sfbayarea.ccnet.com (shamrock@netcom21.netcom.com [192.100.81.135]) by netcom21.netcom.com (8.6.13/Netcom)
	id CAA24618; Tue, 6 May 1997 02:28:01 -0700
Message-Id: <3.0.32.19970506022902.00721d3c@netcom13.netcom.com>
X-Sender: shamrock@netcom13.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 06 May 1997 02:29:23 -0700
To: onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: Thanks for the dinner and some pointers
Cc: reiter@research.att.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

I would like to thank everybody that showed up for the Onion Dinner and of
course would like to thank our host Raph for organizing it.

Some issues came up during the our conversation that I would like to address.

o I think it is clear that we all have the same goal: to provide a privacy
protecting infrastructure for near real-time net connections. Sure, some
people out there will flame you because they are convinced that it all is
giant plot by NSA/NRL/AT&T, undoubtedly organized by the Illuminati, the
Elders of Zion, and of course the Trilateral Commission. The people on this
list do not fall into this category. You'll just have to ignore the nay
sayers, though some of them may have some valid technical advise to
contribute.

o The various systems proposed all have their advantages and drawbacks.
There is good reason to continue parallel development.

o None of us really has any hard numbers to back up their assumptions. I
believe further development would benefit greatly from subjecting the
systems to information theoretic/signal analysis. For example, it seems to
me that we are all just guessing if additional cover traffic has to be
added or not. My experience with remailers suggest it does, others
disagree. But nobody has actually done the math to prove or disprove either
claim.

o For any of these systems to see widespread deployment, they have to work
on other operating systems, especially the free UNIX versions such as
FreeBSD and Linux. Furthermore, the software has to compile with a crypto
library other than the difficult to obtain BSAFE. The first such library
that jumps to mind is the tremendously popular SSLeay, written by Eric
"DES" Young himself. SSLeay tends to produce the fastest code out there. To
quote Ian Goldberg "it is the library RSA wished they were selling."

The SSLeay FAQ is available from http://www.psy.uq.oz.au/~ftp/Crypto
It lists the numerous world wide distribution sites.

That's all for now. Time to go to bed :-)




-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Tue May  6 05:36:52 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10122; Tue, 6 May 97 05:36:52 EDT
Received: from netcom21.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10116; Tue, 6 May 97 05:36:45 EDT
Received: from sfbayarea.ccnet.com (shamrock@netcom21.netcom.com [192.100.81.135]) by netcom21.netcom.com (8.6.13/Netcom)
	id CAA25226; Tue, 6 May 1997 02:36:41 -0700
Message-Id: <3.0.32.19970506023752.00721d3c@netcom13.netcom.com>
X-Sender: shamrock@netcom13.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 06 May 1997 02:38:03 -0700
To: onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: FWD: more RSA numbers
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Here are some numbers the NRL folks might find interesting.

>Return-Path: <coderpunks-errors@toad.com>
>Date: Fri, 2 May 1997 11:05:03 +1000 (EST)
>From: Eric Young <eay@cryptsoft.com>
>To: coderpunks@toad.com
>Subject: more RSA numbers
>Sender: owner-coderpunks@toad.com
>X-Status: 
>
>
>I was able to build my current SSLeay release on a 400mhz DEC Alpha (21164A)
>last night and some of the RSA numbers are quite interesting.
>Definitly the crypto CPU of choice if you can get a large enough heat sink
>into the room :-).
>
>Surfice it to say, I can see the SET processing yards either with lots of
>hardware or lots of alphas :-).
>
>		alpha-400 ppro-200 R10k-195 usparc-167 PCC604-100 pent-100
>rsa  512 bits	0.003s	  0.010s   0.008s   0.021s     0.019s     0.024s
>rsa 1024 bits	0.013s    0.045s   0.043s   0.127s     0.096s     0.119s
>rsa 2048 bits	0.081s    0.260s   0.280s   0.891s     0.614s     0.744s
>rsa 4096 bits	0.583s    1.690s   2.064s   6.805s     4.433s     5.430s
>
>or in RSA/sec
>
>rsa  512 bits	333.3     100.0    125.0     47.6       52.6       41.6
>rsa 1024 bits    76.9      22.2     23.2      7.8       10.4        8.4
>rsa 2048 bits    12.3       3.8      3.5      1.1        1.6        1.3
>
>assuming every-one ramps upto 400mhz and things scale linearly
>
>rsa  512 bits   333.3     200.0    256.4    114.0      210.4      166.4
>rsa 1024 bits    76.9      44.4     47.5     27.3       41.6       33.6
>rsa 2048 bits    12.3       7.6      7.1      2.5        6.4        5.2
>
>So on a clock for clock, the alpha is good but the pentium pro is not bad.
>The alpha takes a hit at the low end because the C code becomes a bit of
>a bottle neck (the RSA multiplies are only 256^256%256 so only 4*4 arrays
>are being multipied.
>
>The caveats are that the alpha uses asm to get 64*64->128 and the pentium
>pro/pentium uses asm but then the architeture is retarded :-).  The R10000
was
>only compiling in 32bit mode (the 64bit compiler was not installed :-(. 
>Potentially its numbers could be 2 times better.  Otherwise all systems were
>running under unix and either using system compilers or gcc. 
>
>Oh, for the block ciphers/digests...
>			Alpha 400	ppro 200
>	MD5          -> 26700k/s	16800k/s
>        SHA1         -> 15900k/s	 9340k/s
>        RC4          -> 19300k/s	15260k/s
>	des-cbc      ->  4920k/s	 3980k/s
>	3des-cbc     ->  1850k/s	 1563k/s
>        blowfish-cbc ->  9672k/s	 6220k/s
>	These are all for 32k blocks and no special tweaking to the code,
>	(except for the DES asm for the pentium pro).
>
>eric (with more numbers....)
>
>
>

-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Tue May  6 12:38:46 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA26212; Tue, 6 May 97 12:38:46 EDT
Received: from einstein.veriweb.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA26204; Tue, 6 May 97 12:38:39 EDT
Received: (from jeremey@localhost) by einstein.veriweb.com (8.8.5/8.6.9) id JAA04546; Tue, 6 May 1997 09:42:11 -0700
Message-Id: <336F5F60.574F34C0@veriweb.com>
Date: Tue, 06 May 1997 09:42:08 -0700
From: Jeremey Barrett <jeremey@veriweb.com>
Organization: VeriWeb Internet Corp.
X-Mailer: Mozilla 4.0b3C (X11; I; Linux 2.0.11 i586)
To: Raph Levien <raph@acm.org>, onions@itd.nrl.navy.mil
Subject: Dinner
X-Priority: 3 (Normal)
References: <336E3B29.16D0B9B0@acm.org>
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

My apologies for not making the dinner. I was on a "non-stop" flight
on Reno Air, which stopped in Las Vegas for two hours and changed 
planes.

Jeremey.
- -- 
Jeremey Barrett                                  VeriWeb Internet Corp.
Crypto, Ecash, Commerce Systems                 http://www.veriweb.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM29fYi/fy+vkqMxNAQFawQQAsxF5X28EIzZ/YZiY1e+nFMFiLZhR0onp
KnG8fgPnrjC2RgtsT98WGUmjjJDSUGD9+acObDfC5UFbvZBnoGRHjQyjjsIlTL6L
ae+HFwryzCWWN5YTNH13GU7Gxu/ebqUqJiUaqZLHNr1sW+zlDcajDl3ypocqxPMS
dZpyoqB22rk=
=tSR+
-----END PGP SIGNATURE-----

From majordom  Wed May  7 20:19:28 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA12063; Wed, 7 May 97 20:19:28 EDT
Received: from golem.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA12056; Wed, 7 May 97 20:19:23 EDT
Received: (from goldschl@localhost) by golem.itd.nrl.navy.mil (8.8.5/8.7.3) id UAA06482; Wed, 7 May 1997 20:19:20 -0400 (EDT)
Date: Wed, 7 May 1997 20:19:20 -0400 (EDT)
Message-Id: <199705080019.UAA06482@golem.itd.nrl.navy.mil>
From: David Goldschlag <goldschl@itd.nrl.navy.mil>
To: onions@itd.nrl.navy.mil
Subject: dinner, etc.
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


Hi,

I'd like to thank Raph for a wonderful dinner and a very interesting
evening.  I am very hopeful that we can work together to develop an
infrastructure for private communication.

Over the next few days, we will get our system running on both Solaris
2.5 and 2.4.  We'll also integrate SSLeay, so the crypto will not
introduce licensing issues.  At that point, we'll be ready to release
(in North America) source and binary codes to anyone who has mailed me
a signed license/non-disclosure agreement.

Several of you have volunteered to run beta onion routers.  If you are
running 2.5, we can integrate your machine into the onion network now.
If you are running 2.4, we'll have to wait a bit.

Our near term plans after that are to develop a careful attack model
of onion routing and write it up.  We are also re-architecting the
system and will try to make the new implementation as portable as we
can.

Thanks,
David.


Here's an adequate license/non-disclosure letter, that Paul might
write, if he needed to and wanted to test the system.


From:
Paul Syverson
Naval Research Laboratory 
Washington, DC 20375-5337
(202) 767-2389
syverson@itd.nrl.navy.mil

To:
David Goldschlag
Naval Research Laboratory 
Center for High Assurance Computer Systems
Washington, DC 20375-5337
(202) 404-7310


Dear David:

I would like to experiment with Onion Routing.  I am a US citizen, and
I agree not to redistribute the source or binary code, and to provide
reasonable protection against its unintended redistribution.

I understand that this license is valid only through the end of 1997,
and may be revoked earlier by the US government, and agree to destroy
my copies of the code at that time.


Yours truly,

(Paul's real signature here)


Paul Syverson


From majordom  Thu May  8 00:45:17 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16423; Thu, 8 May 97 00:45:17 EDT
Received: from netcom18.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16417; Thu, 8 May 97 00:45:12 EDT
Received: from sfbayarea.ccnet.com (shamrock@netcom18.netcom.com [192.100.81.131]) by netcom18.netcom.com (8.6.13/Netcom)
	id VAA16983; Wed, 7 May 1997 21:45:08 -0700
Message-Id: <3.0.32.19970507214556.0070de00@netcom13.netcom.com>
X-Sender: shamrock@netcom13.netcom.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 07 May 1997 21:46:10 -0700
To: onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: Re: dinner, etc.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 08:19 PM 5/7/97 -0400, David Goldschlag wrote:
[...]
>Over the next few days, we will get our system running on both Solaris
>2.5 and 2.4.  We'll also integrate SSLeay, so the crypto will not
>introduce licensing issues.

Patent licensing is an odd area and I certainly won't claim to understand
completely. IANAL and all that. But I have a decent working knowledge of
the topic.

Using SSLeay has many advantages. Amongst them is the fact that SSLeay is
widely available, solidly coded, fast, and talking care of all the ugly
X.509 stuff for you (the latter not being applicable for Onion Routers).
Oh, and SSLeay is widely portable.

But SSLeay does not fully solve all patent issues. Using SSLeay in the US
is generally considered fine as long as the project falls under the
research exemption of the patent law. At this stage, Onion Routers should
have no problem meeting this requirement. However, at some stage and for
some users, the research exemption may no longer be met. For such a
situation, it may be beneficial to be able to use BSAFE.

I would suggest that the Onion Routers use SSLeay as the interface. But you
also may want to consider writing some glue between the SSLeay interface
and BSAFE for those that wish to use BSAFE.

Funny tidbit: BSAFE uses Eric Young's code for DES. But it uses an older
version of his code. I am told that he meanwhile has achieved a 30% speed
increase which is reflected in the latest versions of SSLeay.

Pointer: the company selling the SCSI RSA accelerator is nCipher
http://www.ncipher.com/



-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

   "I do believe that where there is a choice only between cowardice and
    violence, I would advise violence." Mahatma Gandhi

From majordom  Thu Jun 12 02:58:43 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA27814; Thu, 12 Jun 97 02:58:43 EDT
Received: from netcom4.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA27808; Thu, 12 Jun 97 02:58:35 EDT
Received: from slirp.netcom.com (ppp-206-170-4-53.wnck11.pacbell.net [206.170.4.53]) by netcom4.netcom.com (8.6.13/Netcom)
	id XAA21609; Wed, 11 Jun 1997 23:58:33 -0700
Message-Id: <3.0.2.32.19970612000004.03be128c@netcom13.netcom.com>
X-Sender: shamrock@netcom13.netcom.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32)
Date: Thu, 12 Jun 1997 00:00:04 -0700
To: onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: Status?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

How are the Onion Routers coming along?

Waiting to be a beta tester,

--Lucky Green <shamrock@netcom.com> PGP encrypted mail preferred.

  Put a stake through the heart of DES! Join the quest at
  http://www.frii.com/~rcv/deschall.htm

From majordom  Thu Jun 12 08:32:19 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA05095; Thu, 12 Jun 97 08:32:19 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA05089; Thu, 12 Jun 97 08:32:11 EDT
Date: Thu, 12 Jun 1997 08:32:30 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Lucky Green <shamrock@netcom.com>
Cc: onions@itd.nrl.navy.mil
Subject: Re: Status?
In-Reply-To: <3.0.2.32.19970612000004.03be128c@netcom13.netcom.com>
Message-Id: <Pine.GSO.3.95.970612082618.23003B-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 12 Jun 1997, Lucky Green wrote:
|>How are the Onion Routers coming along?

Things were put on hold for a few weeks as our entire branch moved
offices.  I'm sure you can imagine the disarray :-) Anyway, I recently
got back into the swing of things and I've managed to pound out a
series of bugs.  There has also been some pretty heated discussion
here about how to evolve the system (forthcoming -- we're trying to
move this discussion to the onions mailing list).  If all goes well
today and tomorrow, David will be overseeing another distribution next
week while I'm out of town (this probably will still not have SSLEAY
support, but that will be soon...sooner if someone can give me a hand
with the API :-).  We're currently doing some heavy testing of the
system with an automatic tester (we've already flushed out a half
dozen bugs we had no idea existed, and tracked down the last two we
did know about) with a "abuse-rate" of about 40,000 hits per hour with
RSA shut off (it's a lot easier to beat on the system when we don't
run the RSA operations...we test with it on as well, but don't get
nearly as many hits through the system).  More info soon...

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM5/sYk8Qx019l0ClAQE/RwP/ZZU4cqQEKiF196wWRkNDbt4x1gPpMmp6
GrJvMXNsGHmNGZB8XnbBAhR4G5dPi/7DeoJZDXcHszld5SpbKpkXuiwcPwk1WcEb
Arym/EZiX6RSk+c7B6mPSXss+5Acd6qQO9IAzBfkghCisa1YAmu5CYTulzLotvov
UOPic7OCfp8=
=GOF2
-----END PGP SIGNATURE-----


From majordom  Sat Jul 26 01:01:32 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA21121; Sat, 26 Jul 97 01:01:32 EDT
Received: from netcom8.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA21108; Sat, 26 Jul 97 01:01:25 EDT
Received: from slirp.netcom.com (shamrock@netcom6.netcom.com [192.100.81.114]) by netcom8.netcom.com (8.6.13/Netcom)
	id WAA22293; Fri, 25 Jul 1997 22:01:22 -0700
Message-Id: <3.0.2.32.19970725220105.006c68f4@netcom10.netcom.com>
X-Sender: shamrock@netcom10.netcom.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32)
Date: Fri, 25 Jul 1997 22:01:05 -0700
To: onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: Status update, please
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Folks,
What is going on with the Onion Routers? I has been quite a while...

I am waiting to run some sites on FreeBSD/Linux.

How is the port to SSLeay coming?

Thanks,

--Lucky Green <shamrock@netcom.com>
  PGP encrypted mail preferred.
  DES is dead! Please join in breaking RC5-56.
  http://rc5.distributed.net/

From majordom  Mon Jul 28 13:23:09 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16328; Mon, 28 Jul 97 13:23:09 EDT
Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA16315; Mon, 28 Jul 97 13:23:02 EDT
From: syverson@itd.nrl.navy.mil (Paul Syverson)
Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id NAA06790; Mon, 28 Jul 1997 13:22:59 -0400 (EDT)
Date: Mon, 28 Jul 1997 13:22:59 -0400 (EDT)
Message-Id: <199707281722.NAA06790@carnap.itd.nrl.navy.mil>
To: shamrock@netcom.com
Subject: Re: Status update, please
Cc: onions@itd.nrl.navy.mil
X-Sun-Charset: US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


Hi,
We are going to put out another code release this
Friday (Aug. 1). More information will be given soon.
aloha,
Paul
> 
> Folks,
> What is going on with the Onion Routers? I has been quite a while...
> 
> I am waiting to run some sites on FreeBSD/Linux.
> 
> How is the port to SSLeay coming?
> 
> Thanks,
> 
> --Lucky Green <shamrock@netcom.com>
>   PGP encrypted mail preferred.
>   DES is dead! Please join in breaking RC5-56.
>   http://rc5.distributed.net/
> 


From majordom  Tue Jul 29 15:49:25 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA02936; Tue, 29 Jul 97 15:49:25 EDT
Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA02772; Tue, 29 Jul 97 15:45:42 EDT
From: syverson@itd.nrl.navy.mil (Paul Syverson)
Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id PAA00527; Tue, 29 Jul 1997 15:45:32 -0400 (EDT)
Date: Tue, 29 Jul 1997 15:45:32 -0400 (EDT)
Message-Id: <199707291945.PAA00527@carnap.itd.nrl.navy.mil>
To: syverson@itd.nrl.navy.mil, onions@itd.nrl.navy.mil
Subject: latest onion routing code
X-Sun-Charset: US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

 
Greetings Beta Testers and others,

We will release the next version of the onion routing code this Friday
(Aug. 1). It will run on Solaris 2.5 (and Solaris 2.4?).  Since the
last release we have spent a good deal of time testing this version and
making it robust. The new release has been running here on Solaris 2.5
since early summer, and it appears to be stable.

This release will *not* do mixing.  We attempted to build the previous
version by adding mixing to other components, knowing that we would
eventually have to redesign the whole implementation, but the result
generated an apparently inexhaustible supply of hard-to-find bugs.
Reluctantly, we have decided to cut our losses and release this version
with the mixing code commented out.  We are proceeding with a redesign
that will both include mixing and improve performance.  Onion routers
running the redesigned system, when available, should interoperate with
those running the current release.

We are looking forward to the participation of the beta testers in a
network of onion routers.  So far, we are still running a single
machine that simulates a five hop network.  Please let us know if you
would like to be part of such a network.  Participation would probably
entail some reasonable commitment on your part to operate your node for
predictable time periods.

Anyone who has already sent a nondisclosure agreement will receive the
code.  Anyone who would like to become a beta tester, or just receive
code, should contact us at onion-info@itd.nrl.navy.mil for information
on what is necessary.

Finally, we regret to announce that David Goldschlag has decided to
leave NRL for greener pastures.  The project continues, (and we expect
to remain in touch with him), but I will replace him as the primary
point of contact for the project.
  

Sincerely,
Paul Syverson

From majordom  Wed Jul 30 03:30:08 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA03834; Wed, 30 Jul 97 03:30:08 EDT
Received: from smtp1.xs4all.nl by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA03824; Wed, 30 Jul 97 03:29:49 EDT
Received: from lucky.xs4all.nl (asd03-10.dial.xs4all.nl [194.109.44.75]) by smtp1.xs4all.nl (8.8.6/XS4ALL) with SMTP id JAA28824; Wed, 30 Jul 1997 09:29:46 +0200 (MET DST)
Message-Id: <3.0.2.32.19970730090424.0072e9d0@netcom10.netcom.com>
X-Sender: shamrock@netcom10.netcom.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32)
Date: Wed, 30 Jul 1997 09:04:24 -0700
To: syverson@itd.nrl.navy.mil, onions@itd.nrl.navy.mil
From: Lucky Green <shamrock@netcom.com>
Subject: Re: latest onion routing code
In-Reply-To: <199707291945.PAA00527@carnap.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 03:45 PM 7/29/97 -0400, Paul Syverson wrote:
> 
>Greetings Beta Testers and others,
>
>We will release the next version of the onion routing code this Friday
>(Aug. 1). It will run on Solaris 2.5 (and Solaris 2.4?).  Since the
>last release we have spent a good deal of time testing this version and
>making it robust. The new release has been running here on Solaris 2.5
>since early summer, and it appears to be stable.

When will we see the Linux and FreeBSD ports? Did you move to SSLeay?


--Lucky Green <shamrock@netcom.com>
  PGP encrypted mail preferred.
  DES is dead! Please join in breaking RC5-56.
  http://rc5.distributed.net/

From majordom  Wed Jul 30 07:47:50 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA08604; Wed, 30 Jul 97 07:47:50 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA08555; Wed, 30 Jul 97 07:46:24 EDT
Date: Wed, 30 Jul 1997 07:46:46 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Lucky Green <shamrock@netcom.com>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: latest onion routing code
In-Reply-To: <3.0.2.32.19970730090424.0072e9d0@netcom10.netcom.com>
Message-Id: <Pine.GSO.3.95.970730074436.3983B-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 30 Jul 1997, Lucky Green wrote:
|>>We will release the next version of the onion routing code this Friday
|>>(Aug. 1). It will run on Solaris 2.5 (and Solaris 2.4?).  Since the
|>>last release we have spent a good deal of time testing this version and
|>>making it robust. The new release has been running here on Solaris 2.5
|>>since early summer, and it appears to be stable.
|>
|>When will we see the Linux and FreeBSD ports? Did you move to SSLeay?

There will be no ports or SSLeay support in this release.  The new
version that we will be working on will be built on top of SSLeay and
be portable from the start.  We just had to much legacy code in there
that would have required rewriting to make it worth while at this
time, instead we'll just do it right the second time around.

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM98prU8Qx019l0ClAQG9PgQAmhweGaf8BX7ueV0v2mIwAhz6gS1X0qat
uP/xFD6pZrQ790pCfz1w7T1GJSDt0neDSD4F0YJus6/7LdaJ2GDsqB99SpwiQlaD
Pd7NPdKX5RDOcFlaOQ4Ow3HAQ/Ea7WbHrz0Xeeg9i/vmMG6+9AdxU0EyGiqTHvUa
Weq+wFYDrvY=
=NYDq
-----END PGP SIGNATURE-----


From majordom  Fri Aug  1 16:22:46 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA28453; Fri, 1 Aug 97 16:22:46 EDT
Received: from carnap.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA28309; Fri, 1 Aug 97 16:19:03 EDT
From: syverson@itd.nrl.navy.mil (Paul Syverson)
Received: (from syverson@localhost) by carnap.itd.nrl.navy.mil (8.8.5/8.7.3) id QAA03639; Fri, 1 Aug 1997 16:18:59 -0400 (EDT)
Date: Fri, 1 Aug 1997 16:18:59 -0400 (EDT)
Message-Id: <199708012018.QAA03639@carnap.itd.nrl.navy.mil>
To: onion-info@itd.nrl.navy.mil
Subject: Onion Routing Version 1.0 code now available
X-Sun-Charset: US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


Source and binaries for Onion Routing Version 1.0 are now available.
(A brief desription of onion routing is given below.) Anyone interested
in receiving the code is encouraged to contact us at onion-info@nrl.navy.mil
The only restriction on receiving the code is that you be a US citizen
and sign a nondisclosure agreement. Anyone who feels s/he should
have already received code and has not should contact us.

We are also looking for parties interested in serving as sites in our
first distributed beta network. Anyone interested in running an onion
router in the beta network should contact us (even if you already did
during our first attempt at a beta network this spring). Minimal
requirements are a Sun Sparc running Solaris 2.5 or later; contact us
at onion-info@itd.nrl.navy.mil for detailed questions. We will gather
interested sites until next Friday (August 8, 1997). At that point we
will assemble a first beta network out of the sites that have contacted
us.  Beta sites will be given config files and private keys at that
time.  Our first network will be a static, persistent, fully connected
clique.  We will be able to add or remove interested sites later, but
this will involve a redistribution of config files to the entire
network.

--------------------------------------------------------------------


			    Onion Routing

                      Naval Research Laboratory
               Center for High Assurance Computer Systems
        http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing

Onion Routing is an infrastructure for private communication over a
public network.  It provides anonymous connections that are strongly
resistant to both eavesdropping and traffic analysis.  Onion routing's
anonymous connections are bidirectional and near real-time, and can be
used anywhere a socket connection can be used.  A prototype of onion
routing is running in our lab.

An onion is a data structure that is treated as the destination
address by onion routers; thus, it is used to establish an anonymous
connection. Onions themselves appear differently to each onion router
as well as to network observers. The same goes for data carried over
the connections they establish.  Proxy aware applications, such as web
browsing and email, require no modification to use onion routing, and
do so through a series of proxies.

This work sponsored by DARPA, NRL, and ONR. 

From majordom  Mon Aug  4 12:47:08 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA29495; Mon, 4 Aug 97 12:47:08 EDT
Received: from descartes.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA29458; Mon, 4 Aug 97 12:46:57 EDT
Received: from galileo.bluemoney.com (galileo.bluemoney.com [204.162.247.73]) by descartes.bluemoney.com (8.7/8.6.9) with SMTP id JAA06591; Mon, 4 Aug 1997 09:49:26 -0700 (PDT)
Message-Id: <3.0.2.32.19970804094622.008426d0@descartes.bluemoney.com>
X-Sender: jeremey@descartes.bluemoney.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 04 Aug 1997 09:46:22 -0700
To: syverson@itd.nrl.navy.mil
From: Jeremey Barrett <jeremey@bluemoney.com>
Subject: Code comments
Cc: onions@itd.nrl.navy.mil
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Some initial suggestions regarding the code:

 o Use pthreads instead of Solaris threads. You can quickly replace
   the code, the two libs match up pretty well. (pthread_create 
   instead of thr_create, pthread_mutex_init instead of mutex_init,
   etc). I would assume a pthreads implementation exists for
   Solaris, probably as wrappers for Solaris threads. pthreads
   exist in some form or another on many platforms. (It might also
   be worth looking into whether threads are necessary at all).

 o poll(). Icky. Is there a reason you chose poll() over select()?
   select() will be much more portable. AFAIK, poll() doesn't
   exist outside of system V.

 o The dead horse: BSAFE. :-) But it looks as though you've already
   wrapped BSAFE up in your own calls, so writing an SSLeay
   interface should be pretty easy.

I haven't perused or compiled everything yet. Thanks for the release,
I'll keep you posted.

Jeremey.

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBM+YHXS/fy+vkqMxNAQGWHwP/Xp6R/huwsRGLIX75BewgDyq5u7SGxBfc
Pi5s/8zmTZWZrGewUxaQn0kMjeJXBUKbCGZ419JGNuGePfLTvv3p5FP3PcvOXqJZ
qZSDKHwgqJlsWWoxfJYbbO4c5lVUsdYBnRRkFu7wd/2hpGyhOrdPSUBbo6VGzfRZ
K7sQZzi0DxY=
=yTll
-----END PGP SIGNATURE-----

--
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64


From majordom  Mon Aug  4 13:06:24 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA00797; Mon, 4 Aug 97 13:06:24 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA00788; Mon, 4 Aug 97 13:06:17 EDT
Date: Mon, 4 Aug 1997 13:06:44 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Jeremey Barrett <jeremey@bluemoney.com>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Code comments
In-Reply-To: <3.0.2.32.19970804094622.008426d0@descartes.bluemoney.com>
Message-Id: <Pine.GSO.3.95.970804130014.11945B-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Mon, 4 Aug 1997, Jeremey Barrett wrote:
|> o Use pthreads instead of Solaris threads. You can quickly replace
|>   the code, the two libs match up pretty well. (pthread_create 
|>   instead of thr_create, pthread_mutex_init instead of mutex_init,
|>   etc). I would assume a pthreads implementation exists for
|>   Solaris, probably as wrappers for Solaris threads. pthreads
|>   exist in some form or another on many platforms. (It might also
|>   be worth looking into whether threads are necessary at all).

Actually, I've been meaning to do that for some time.  In the next
version, I am thinking of avoiding threading all together and just
using several heavy weight processes loosely interconnected via shared
memory or IPC calls.  I've found the Solaris threads to be buggy (we
have two known bugs that we worked around in this release alone), and
I'm not sure how confident I am in pthreads considering they were only
recently adopted as a POSIX standard, correct?  Comments?

|> o poll(). Icky. Is there a reason you chose poll() over select()?
|>   select() will be much more portable. AFAIK, poll() doesn't
|>   exist outside of system V.

Yes, I know.  You go with what you know though...Since the initial
version was a proof of concept, I just used poll.  That will change.

|> o The dead horse: BSAFE. :-) But it looks as though you've already
|>   wrapped BSAFE up in your own calls, so writing an SSLeay
|>   interface should be pretty easy.

Already been suggested and is currently being worked on.  Prior to
BSAFE we used Bell Lab's CryptoLib, but since it isn't completely
thread safe, we dropped it.  We also interface into fast RSA routines
for the SPARC v9+ architecture with the same call structure as BSAFE.
Since we are looking to go to a Intel platform with cheap crypto
hardware or fast crypto software (SSLeay), this will change too...

|>I haven't perused or compiled everything yet. Thanks for the release,
|>I'll keep you posted.

Keep in mind that we are throwing out all of this code for the next
release.  This version was a proof of concept only, and is *NOT*
intended to be used widely or heavily.  We made every attempt possible
to make it pretty robust, but next time we "plan on doing it right"
:-) Therefore, all comments and criticisms are appreciated.  Look for
more details on the design of the new system here next week (we're
banging out the details as we speak).

- -Michael
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From majordom  Mon Aug  4 13:15:59 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA01291; Mon, 4 Aug 97 13:15:59 EDT
Received: from descartes.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA01282; Mon, 4 Aug 97 13:15:48 EDT
Received: from galileo.bluemoney.com (galileo.bluemoney.com [204.162.247.73]) by descartes.bluemoney.com (8.7/8.6.9) with SMTP id KAA06642; Mon, 4 Aug 1997 10:18:17 -0700 (PDT)
Message-Id: <3.0.2.32.19970804101513.00807690@descartes.bluemoney.com>
X-Sender: jeremey@descartes.bluemoney.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32)
Date: Mon, 04 Aug 1997 10:15:13 -0700
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
From: Jeremey Barrett <jeremey@bluemoney.com>
Subject: Re: Code comments
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
In-Reply-To: <Pine.GSO.3.95.970804130014.11945B-100000@banana-jr.itd.nrl
 .navy.mil>
References: <3.0.2.32.19970804094622.008426d0@descartes.bluemoney.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

At 01:06 PM 8/4/97 -0400, Michael G. Reed wrote:

>On Mon, 4 Aug 1997, Jeremey Barrett wrote:
>|> o Use pthreads instead of Solaris threads. You can quickly replace
>|>   the code, the two libs match up pretty well. (pthread_create 
>|>   instead of thr_create, pthread_mutex_init instead of mutex_init,
>|>   etc). I would assume a pthreads implementation exists for
>|>   Solaris, probably as wrappers for Solaris threads. pthreads
>|>   exist in some form or another on many platforms. (It might also
>|>   be worth looking into whether threads are necessary at all).
>
>Actually, I've been meaning to do that for some time.  In the next
>version, I am thinking of avoiding threading all together and just
>using several heavy weight processes loosely interconnected via shared
>memory or IPC calls.  I've found the Solaris threads to be buggy (we
>have two known bugs that we worked around in this release alone), and
>I'm not sure how confident I am in pthreads considering they were only
>recently adopted as a POSIX standard, correct?  Comments?

In my experience, pthreads are pretty buggy too. :-) I think the best 
solution is no threads at all. The only platform on which pthreads
seem to work well is linux (LinuxThreads implementation) because
they are based on clone(), and actually create a different light
process for each thread. So you don't have to replace all of libc,
because normal blocking system calls are fine.

Most pthreads implementations I've used are user-level, and choke
horribly on things like select().

>
>Keep in mind that we are throwing out all of this code for the next
>release.  This version was a proof of concept only, and is *NOT*
>intended to be used widely or heavily.  We made every attempt possible
>to make it pretty robust, but next time we "plan on doing it right"
>:-) Therefore, all comments and criticisms are appreciated.  Look for
>more details on the design of the new system here next week (we're
>banging out the details as we speak).

Great, looking forward to it.

Jeremey.
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From majordom  Tue Aug  5 07:45:45 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA29514; Tue, 5 Aug 97 07:45:45 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA29507; Tue, 5 Aug 97 07:45:39 EDT
Date: Tue, 5 Aug 1997 07:46:06 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Some questions...
Message-Id: <Pine.GSO.3.95.970805071504.12746A-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Calling all Onioneers!

	Now that we are redesigning the system from ground up, we are
considering a few fundamental changes that may render new versions of
the Onion Routing software incompatible with the current prototype.
Before we take those drastic steps though, we want to get some
feedback/comments on them.  Constructive criticism would really be 
appreciated!


Question #1: Keep or ditch ATM sized cells?

The original assumption was that there would be a good mix (no pun
intended) of data traffic between interactive services (RLOGIN) and
bulk transport services (HTTP/FTP/SMTP).  This has not proven to be
the case (we have 70k HTTP hits in the last two weeks and only 3
RLOGIN hits).  We also adopted cell sizes that would fit within ATM
cells so we could run directly over ATM/AAL5 instead of TCP/IP.  With
some people lamenting that ATM to the desktop is dead and it will only
ever be used as a WAN transport mechanism (and even then, most of the
time people tend to use PVCs with IP running over them), should we
continue to constrain ourselves to this small size (48 byte cells --
in the case of data cells that's 44 byte payload and 4 byte header),
or is a larger size in order?  The 8.3% overhead we currently have is
pretty high, and will only get larger if we add MACs (see the next
question).  If we increase cell size we will increase system
throughput and reduce cell overhead.  Comments?


Question #2: Add a mandatory end-to-end data MAC, an optional
end-to-end data MAC, and/or OR-to-OR link MACs?

Proxy classically offer services that may be weaker than the TCP/IP
connections they run over.  This is due to the fact that the proxy may
alter the data (intentionally or not) while relaying it from one side
to the other.  We run into a potentially larger problem with OR.
There is nothing to prevent a malicious OR from tampering with the
data stream.  By using the stream ciphers, we guard against
replay/data injection/data removal in the sense the data stream will
become corrupted, but the application may not KNOW the data stream is
corrupted.  Currently there is no MAC in place and we've been
discussing this for a little while.  Does a vanilla CRC-16 inside the
data messages (and secured by the multiple stream ciphers) add the
level of security we should probably be providing?  If we put it into
the data cells, are OR-to-OR link MACs necessary?  We have some ideas
and answers on this, but I want to hear other peoples opinions.


Question #3: Keep or increase the ACI length?

The ACI (Anonymous Connection Identifier) field in each cell is
currently 16 bits long.  This allows for 64K connections through any
one OR-to-OR link.  Because we need an asymmetry during connection
setup, this really amounts to a 32K address space in both directions
(we carve it in half).  Does this seem sufficient?  Can anyone forsee
a situation where there are more than 40K or 50K connections up
simultaneously between two particular OR's?  This would require a
redesign of the header, so I am reluctant to endorse the idea, but
some have raised the question about this limitation and I'd really
like to hear some good arguments on it.


Question #4: Run multi-threaded or single-threaded servers that
communicate via IPC/shared memory?

Multi-threaded applications are nice in that the entire server is self
contained.  However, there are a number of drawbacks as well: 1) they
tend to be more difficult to debug, 2) POSIX threads have one recently
been adopted so are not available on all platforms, 3) many thread
implementations are buggy.  The first prototype was a multi-threaded
application, and given that experience, I am thinking of going the
later route this time around.


Question #5: Crypto of choice?

Software: SSLeay -- it's fast and portable.  Hardware: ?  -- we're
looking at PCI based, publicly available crypto boards now.  If anyone
has a suggestion, we're all ears.  Support for DES-56/RSA-1024/DH is
critical.  Any other protocols (MD5/IDEA/etc) would be gravy.


That's all for now.  Look for more details on the changes in the new
system to come in a few days...Thanks for the help!

-Michael


From majordom  Tue Aug  5 13:35:16 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA17572; Tue, 5 Aug 97 13:35:16 EDT
Received: from einstein.bluemoney.com ([204.162.247.69]) by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA17455; Tue, 5 Aug 97 13:35:09 EDT
Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id KAA02326; Tue, 5 Aug 1997 10:37:17 -0700
Date: Tue, 5 Aug 1997 10:37:17 -0700
Message-Id: <199708051737.KAA02326@einstein.bluemoney.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Some questions...
In-Reply-To: <Pine.GSO.3.95.970805071504.12746A-100000@banana-jr.itd.nrl.navy.mil>
References: <Pine.GSO.3.95.970805071504.12746A-100000@banana-jr.itd.nrl.navy.mil>
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
From: Jeremey Barrett <jeremey@bluemoney.com>
Organization: BlueMoney Software Corp.
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

 > 
 > Question #1: Keep or ditch ATM sized cells?

Ditch. I imagine running over TCP/IP is nearly a given, and
you can achieve better/more efficient messages formats.

 > Question #2: Add a mandatory end-to-end data MAC, an optional
 > end-to-end data MAC, and/or OR-to-OR link MACs?
 > 
 > Proxy classically offer services that may be weaker than the TCP/IP
 > connections they run over.  This is due to the fact that the proxy may
 > alter the data (intentionally or not) while relaying it from one side
 > to the other.  We run into a potentially larger problem with OR.
 > There is nothing to prevent a malicious OR from tampering with the
 > data stream.  By using the stream ciphers, we guard against
 > replay/data injection/data removal in the sense the data stream will
 > become corrupted, but the application may not KNOW the data stream is
 > corrupted.  Currently there is no MAC in place and we've been
 > discussing this for a little while.  Does a vanilla CRC-16 inside the
 > data messages (and secured by the multiple stream ciphers) add the
 > level of security we should probably be providing?  If we put it into
 > the data cells, are OR-to-OR link MACs necessary?  We have some ideas
 > and answers on this, but I want to hear other peoples opinions.

It will be pretty hard to protect against a malicious router.
Regardless of MAC, the router can rewrite an onion at connection
setup time (am I off base here?). A MAC might be useful for the 
OR-to-OR link, to protect against outside attackers modifying the 
data stream.

 > 
 > 
 > Question #3: Keep or increase the ACI length?
 > 
 > The ACI (Anonymous Connection Identifier) field in each cell is
 > currently 16 bits long.  This allows for 64K connections through any
 > one OR-to-OR link.  Because we need an asymmetry during connection
 > setup, this really amounts to a 32K address space in both directions
 > (we carve it in half).  Does this seem sufficient?  Can anyone forsee
 > a situation where there are more than 40K or 50K connections up
 > simultaneously between two particular OR's?  This would require a
 > redesign of the header, so I am reluctant to endorse the idea, but
 > some have raised the question about this limitation and I'd really
 > like to hear some good arguments on it.

They said 32 bits was way more than enough for IP addresses :-)
Maybe have a 1 byte version indicator, so you can later upgrade 
the protocol without breaking everything. Seems like a max of
32K connections is low, given the number of people out there,
but I really don't know how much use the system will get.

 > 
 > 
 > Question #4: Run multi-threaded or single-threaded servers that
 > communicate via IPC/shared memory?

Out of curiosity, why are multiple servers necessary? In any case,
a non-threaded implementation will be more portable and much easier
to debug, as you say. Go without threads.

 > Question #5: Crypto of choice?
 > 
 > Software: SSLeay -- it's fast and portable.  Hardware: ?  -- we're
 > looking at PCI based, publicly available crypto boards now.  If anyone
 > has a suggestion, we're all ears.  Support for DES-56/RSA-1024/DH is
 > critical.  Any other protocols (MD5/IDEA/etc) would be gravy.

I'd recommend nCipher's hardware. It runs on the SCSI bus, so the
driver is entirely user-space, no kernel modifications required.
It's also quite fast.

Jeremey.

- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
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From majordom  Tue Aug  5 16:37:41 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA27448; Tue, 5 Aug 97 16:37:41 EDT
Received: from freya.cs.umass.edu by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA27440; Tue, 5 Aug 97 16:37:35 EDT
Received: from opine.cs.umass.edu (opine.cs.umass.edu [128.119.41.246])
	by freya.cs.umass.edu (8.8.5/8.8.5) with SMTP id QAA25501
	for <onions@itd.nrl.navy.mil>; Tue, 5 Aug 1997 16:37:34 -0400
Message-Id: <33E78F0E.167E@cs.umass.edu>
Date: Tue, 05 Aug 1997 16:37:34 -0400
From: Lewis McCarthy <lmccarth@cs.umass.edu>
Organization: UMass-Amherst Theoretical Computer Science Group, <http://www.cs.umass.edu/~thtml/>
X-Mailer: Mozilla 3.01Gold (X11; U; OSF1 V3.2 alpha)
Mime-Version: 1.0
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Some questions...
References: <Pine.GSO.3.95.970805071504.12746A-100000@banana-jr.itd.nrl.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

Michael Reed writes:
> Question #2: Add a mandatory end-to-end data MAC, an optional
> end-to-end data MAC, and/or OR-to-OR link MACs?
> 
> Proxy classically offer services that may be weaker than the TCP/IP
> connections they run over.  This is due to the fact that the proxy may
> alter the data (intentionally or not) while relaying it from one side
> to the other.  We run into a potentially larger problem with OR.
> There is nothing to prevent a malicious OR from tampering with the
> data stream.  By using the stream ciphers, we guard against
> replay/data injection/data removal in the sense the data stream will
> become corrupted, but the application may not KNOW the data stream is
> corrupted.  Currently there is no MAC in place and we've been
> discussing this for a little while.  Does a vanilla CRC-16 inside the
> data messages (and secured by the multiple stream ciphers) add the
> level of security we should probably be providing?  

I don't believe this would add much real strength. If I read you 
correctly, you're suggesting a construction with a single CRC inside 
the innermost encryption layer, such as:
Encrypt_m( ... Encrypt_2( Encrypt_1( DATA, CRC16( DATA ) ) ) ... ).
Since each encryption layer Encrypt_i() is an application of a stream
cipher, we have (DATA, CRC16(DATA)) xor KeyStream_1 xor KeyStream_2 ...
xor KeyStream_m == (DATA, CRC16(DATA)) xor Composite-KeyStream. 
If I'm not mistaken, an attacker can flip some bits in the DATA xor
LeftBits(Composite-Keystream) portion, and quickly figure out which
bits should be flipped in the CRC16(DATA) xor RightBits(Composite-
Keystream) portion. For a while last year there was a proposal in the
IPSEC WG to use a stream cipher in ESP with an embedded CRC as a form
of MAC. This scheme and some suggested fixes were torn open; see the
thread on "A hole in esp-stream-01" in the IPSEC mailing list archives
for Oct. `96 at <ftp://ftp.tis.com/pub/lists/ipsec/ipsec.9610>.

> If we put it into
> the data cells, are OR-to-OR link MACs necessary?  We have some ideas
> and answers on this, but I want to hear other peoples opinions.

Hmm, I haven't thought much about the workfactor for breaking a
construction with multiple nested non-cryptographic checksums.
Intuitively I suspect it may be possible to hurdle them one at a 
time, rather than needing to tackle them all simultaneously.

I'm inclined to vote for an optional end-to-end data MAC, using a
construction with cryptographic teeth like an HMAC with MD5 (or
preferably SHA-1 or RIPEMD160). If people use SSL or TLS on top of
their onion connections then a lower-level MAC is probably
unnecessary anyway. Some folks might be satisfied with IP layer
data integrity protection from IPSEC-AH or -ESP for this purpose, if
they don't need per-connection data origin authentication. I don't
see an exception to the usual end-to-end security arguments here that
would call for deploying link security measures instead.
-- 
Lewis    http://www.cs.umass.edu/~lmccarth/    "In our opinion
provable security is nothing more than a phantom, similar to
the perpetuum mobile in thermodynamics."  -- Joan Daemen, 1995

From majordom  Wed Aug  6 13:05:50 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA28926; Wed, 6 Aug 97 13:05:50 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA28912; Wed, 6 Aug 97 13:05:40 EDT
Date: Wed, 6 Aug 1997 13:06:08 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Jeremey Barrett <jeremey@bluemoney.com>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Some questions...
In-Reply-To: <199708051737.KAA02326@einstein.bluemoney.com>
Message-Id: <Pine.GSO.3.95.970806125831.13712A-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 5 Aug 1997, Jeremey Barrett wrote:
|> > Question #1: Keep or ditch ATM sized cells?
|>
|>Ditch. I imagine running over TCP/IP is nearly a given, and
|>you can achieve better/more efficient messages formats.

Ah, but what size do we select instead?  All packets must be the same
size to avoid traceability in the network...

|> > Question #2: Add a mandatory end-to-end data MAC, an optional
|> > end-to-end data MAC, and/or OR-to-OR link MACs?
|>
|>It will be pretty hard to protect against a malicious router.
|>Regardless of MAC, the router can rewrite an onion at connection
|>setup time (am I off base here?). A MAC might be useful for the 
|>OR-to-OR link, to protect against outside attackers modifying the 
|>data stream.

A malicious router CANNOT rewrite the onion.  He can add layers, but
he cannot remove or replace existing layers of the connection will not
succeed.

|> > Question #3: Keep or increase the ACI length?
|> > 
|> > The ACI (Anonymous Connection Identifier) field in each cell is
|> > currently 16 bits long.  This allows for 64K connections through any
|> > one OR-to-OR link.  Because we need an asymmetry during connection
|> > setup, this really amounts to a 32K address space in both directions
|> > (we carve it in half).  Does this seem sufficient?  Can anyone forsee
|> > a situation where there are more than 40K or 50K connections up
|> > simultaneously between two particular OR's?  This would require a
|> > redesign of the header, so I am reluctant to endorse the idea, but
|> > some have raised the question about this limitation and I'd really
|> > like to hear some good arguments on it.
|>
|>They said 32 bits was way more than enough for IP addresses :-)
|>Maybe have a 1 byte version indicator, so you can later upgrade 
|>the protocol without breaking everything. Seems like a max of
|>32K connections is low, given the number of people out there,
|>but I really don't know how much use the system will get.

Since the ACI is a locally defined parameter on each OR-to-OR link,
there is no reason that in the future it couldn't be expanded by
simply upgrading both OR's on either side of the link.  This would
need to be done as well under your proposal since if you don't upgrade
both, one won't understand the new format (version).  For that reason,
I'm inclined to leave it at 16 bits and see what happens.

|> > Question #4: Run multi-threaded or single-threaded servers that
|> > communicate via IPC/shared memory?
|>
|>Out of curiosity, why are multiple servers necessary? In any case,
|>a non-threaded implementation will be more portable and much easier
|>to debug, as you say. Go without threads.

I tend to agree with you in the "no threads" this time around.
However, I am thinking of simulating threads though with heavy-weight
processes.  IE, I'll have a READ process that takes data from the
various thick pipes and dumps it to the PROCESS process which will do
all the crypto and cross lookups and then forward the data to a WRITE
process.  If I don't do it this way, problems could arise (ie, what
if I can't write all the data...do I block indefinitely stalling
everything, etc).

|> > Question #5: Crypto of choice?
|> > 
|> > Software: SSLeay -- it's fast and portable.  Hardware: ?  -- we're
|> > looking at PCI based, publicly available crypto boards now.  If anyone
|> > has a suggestion, we're all ears.  Support for DES-56/RSA-1024/DH is
|> > critical.  Any other protocols (MD5/IDEA/etc) would be gravy.
|>
|>I'd recommend nCipher's hardware. It runs on the SCSI bus, so the
|>driver is entirely user-space, no kernel modifications required.
|>It's also quite fast.

Their web page is less than stellar (lots of promises, little on
details).  Are they shipping (and if so, WHAT are they shipping)?

Thanks for the input!

- -Michael
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From majordom  Wed Aug  6 14:51:47 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA05010; Wed, 6 Aug 97 14:51:47 EDT
Received: from mail.eskimo.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA05004; Wed, 6 Aug 97 14:51:34 EDT
Received: from eskimo.com (weidai@eskimo.com [204.122.16.13]) by mail.eskimo.com (8.8.5/8.6.12) with SMTP id LAA13727; Wed, 6 Aug 1997 11:51:30 -0700 (PDT)
Date: Wed, 6 Aug 1997 11:51:28 -0700 (PDT)
From: Wei Dai <weidai@eskimo.com>
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Cc: Jeremey Barrett <jeremey@bluemoney.com>,
        Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Some questions...
In-Reply-To: <Pine.GSO.3.95.970806125831.13712A-100000@banana-jr.itd.nrl.navy.mil>
Message-Id: <Pine.SUN.3.96.970806114541.19588C-100000@eskimo.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

On Wed, 6 Aug 1997, Michael G. Reed wrote:

> Ah, but what size do we select instead?  All packets must be the same
> size to avoid traceability in the network...

How about having different classes of service?  For example you can offer
two different packet sizes for rlogin and http services.  This will allow
an adversary to tell the difference between rlogin users and http users,
but I think a one-size-fits-all approach is too inefficient to be
practical.


From majordom  Thu Aug  7 04:07:50 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA24680; Thu, 7 Aug 97 04:07:50 EDT
Received: from uni-sb.de by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA24670; Thu, 7 Aug 97 04:07:41 EDT
Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31])
          by uni-sb.de (8.8.6/97052600) with ESMTP
          id KAA28564 for <onions@itd.nrl.navy.mil>; Thu, 7 Aug 1997 10:07:37 +0200 (CEST)
Received: from fsinfo.cs.uni-sb.de (root@fsinfo.cs.uni-sb.de [134.96.239.10])
          by cs.uni-sb.de (8.8.6/97052600) with ESMTP
          id KAA28318 for <onions@itd.nrl.navy.mil>; Thu, 7 Aug 1997 10:07:37 +0200 (CEST)
Received: from [134.96.113.124] (acc1-124.telip.uni-sb.de [134.96.113.124])
          by fsinfo.cs.uni-sb.de (8.8.6/97070902) with ESMTP
          id KAA10402 for <onions@itd.nrl.navy.mil>; Thu, 7 Aug 1997 10:07:20 +0200 (CEST)
Message-Id: <l03102800b00f315a91bd@[134.96.113.57]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 7 Aug 1997 10:08:20 +0200
To: onions@itd.nrl.navy.mil
From: Lothar Fritsch <fritsch@fsinfo.cs.uni-sb.de>
Subject: Q: rlogin onion router
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk


Hello!

My name is Lothar Fritsch, a new subscriber to the onions list. I'm a
german computer science student at the Universit=E4t des Saarlandes at
Saarbr=FCcken, Germany, working on my thesis on the topic of anonymous
communications in an electronic marketplace.
This is why I'm interested in onion routing. One particular problem I found
in connection-oriented MIXes or onion routers is the problem of the "data
size" sent over the onion router network. Especially for rlogin, where
users hit single keys on their keyboards, the size of the transmitted data
might very well be a single byte. I wonder how this is implemented in the
rlogin onion router: is the single keystroke packaged into a cell with 44
bytes of payload, like Syverson, Goldschlag and Reed wrote in "Anonymous
Connections and Onion Routing" in section 5.6?

Yours,

Lothar Fritsch

--
Lothar Fritsch                        Informatik, Fotografie,
fritsch@fsinfo.cs.uni-sb.de           Internet-Journalist,
http://fsinfo.cs.uni-sb.de/~fritsch/  Neue Medien, Schulungen



From majordom  Thu Aug  7 04:53:37 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA25394; Thu, 7 Aug 97 04:53:37 EDT
Received: from einstein.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA25388; Thu, 7 Aug 97 04:53:30 EDT
Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id BAA01974; Thu, 7 Aug 1997 01:57:14 -0700
Date: Thu, 7 Aug 1997 01:57:14 -0700
Message-Id: <199708070857.BAA01974@einstein.bluemoney.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Some questions...
In-Reply-To: <Pine.GSO.3.95.970806125831.13712A-100000@banana-jr.itd.nrl.navy.mil>
References: <199708051737.KAA02326@einstein.bluemoney.com>
	<Pine.GSO.3.95.970806125831.13712A-100000@banana-jr.itd.nrl.navy.mil>
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
From: Jeremey Barrett <jeremey@bluemoney.com>
Organization: BlueMoney Software Corp.
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

Michael G. Reed writes:
 >
 > Ah, but what size do we select instead?  All packets must be the same
 > size to avoid traceability in the network...

What size I don't know exactly. How much overhead is there? (including
a MAC perhaps). I agree with Wei Dai that it should vary according
to traffic type. rlogin with 256 byte packets would be less than
optimal, similarly HTTP with 53 byte packets.

 > 
 > A malicious router CANNOT rewrite the onion.  He can add layers, but
 > he cannot remove or replace existing layers of the connection will not
 > succeed.

Hrm... then an end-to-end MAC on the data stream seems most useful.
It should be some form of keyed cryptographic hash IMO, probably
HMAC. The key can be derived from the shared symmetric key. The MAC
on the data stream, if valid, will also validate that the setup onion
was not tampered with in any meaningful way.

 > |>I'd recommend nCipher's hardware. It runs on the SCSI bus, so the
 > |>driver is entirely user-space, no kernel modifications required.
 > |>It's also quite fast.
 > 
 > Their web page is less than stellar (lots of promises, little on
 > details).  Are they shipping (and if so, WHAT are they shipping)?

They have a low-end card that does 75 1024 bit RSA sigs a second,
and a high-end around 300. I don't think they are shipping final 
products yet, but they do have a beta program.

Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBM+mNuC/fy+vkqMxNAQGN0gP/fcY+/blYDAcDKX0WklSoKXdwP57fKQAW
1291PEhAj6T3P0MIbjtf0K4eL0s897ukfx1iiZJzUeFb5qEKS7YGltGsXuTTHrWb
gGUgCaMe6YcQthrmJmMy4QYM2uDZBUXkqUwkaiZGYz4FGHVp6xhklhvkcVPQcuPS
+QoTkNltIPk=
=isCU
-----END PGP SIGNATURE-----

From majordom  Thu Aug  7 07:15:43 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA27503; Thu, 7 Aug 97 07:15:43 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA27495; Thu, 7 Aug 97 07:15:25 EDT
Date: Thu, 7 Aug 1997 07:15:52 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Lothar Fritsch <fritsch@fsinfo.cs.uni-sb.de>
Cc: onions@itd.nrl.navy.mil
Subject: Re: Q: rlogin onion router
In-Reply-To: <l03102800b00f315a91bd@[134.96.113.57]>
Message-Id: <Pine.GSO.3.95.970807071334.14345A-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 7 Aug 1997, Lothar Fritsch wrote:
|>My name is Lothar Fritsch, a new subscriber to the onions list. I'm a
|>german computer science student at the Universit=E4t des Saarlandes at
|>Saarbr=FCcken, Germany, working on my thesis on the topic of anonymous
|>communications in an electronic marketplace.
|>This is why I'm interested in onion routing. One particular problem I fou=
nd
|>in connection-oriented MIXes or onion routers is the problem of the "data
|>size" sent over the onion router network. Especially for rlogin, where
|>users hit single keys on their keyboards, the size of the transmitted dat=
a
|>might very well be a single byte. I wonder how this is implemented in the
|>rlogin onion router: is the single keystroke packaged into a cell with 44
|>bytes of payload, like Syverson, Goldschlag and Reed wrote in "Anonymous
|>Connections and Onion Routing" in section 5.6?

Yes, if only a byte of data is available at a time, it is packaged
with 43 bytes of random padding and then sent through the network.
Not the most efficient way of doing it, but not really any worse than
what normally happens on the Internet (one of the more common TCP/IP
packets is the single byte payload at a time interactive telnet
connection).

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM+mubE8Qx019l0ClAQEcQQP9G83TxJFRtvLmOdmS0Pj9yqAsiHIz16VM
pAWEAVGfVdARkGlhSQwId45QgD46Dmok33nMvYLcacqPyYIiUQ0eR8qBbpiZj169
zbuhS8sI2k2xdFq7bNQkH8Wa+qMnvDbxiw6Gs0LTyRpWa9kQMOmgMMRYMNlgIuOP
ikV+leA6zXg=3D
=3DWV56
-----END PGP SIGNATURE-----


From majordom  Thu Aug  7 07:39:07 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA28363; Thu, 7 Aug 97 07:39:07 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA28340; Thu, 7 Aug 97 07:38:53 EDT
Date: Thu, 7 Aug 1997 07:39:20 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Wei Dai <weidai@eskimo.com>
Cc: Jeremey Barrett <jeremey@bluemoney.com>,
        Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Some questions...
In-Reply-To: <Pine.SUN.3.96.970806114541.19588C-100000@eskimo.com>
Message-Id: <Pine.GSO.3.95.970807072232.14345B-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 6 Aug 1997, Wei Dai wrote:
|>> Ah, but what size do we select instead?  All packets must be the same
|>> size to avoid traceability in the network...
|>
|>How about having different classes of service?  For example you can offer
|>two different packet sizes for rlogin and http services.  This will allow
|>an adversary to tell the difference between rlogin users and http users,
|>but I think a one-size-fits-all approach is too inefficient to be
|>practical.

We had discussed the idea of different classes of service, but not in
a data payload size context -- instead in a mixing context.  For
example, you may have high priority data (ie, data that must maintain
a better QoS level like interactive telnet connections) and lower
priority data (ie, smtp transactions).  One could imagine a mixing
strategy that tries to do minimal mixing on the high priority data to
reduce the latency for the data flowing through the network but is
willing to hold low priority data at each node for some time to better
hide everything (after all, the larger the mix pool, the harder it
becomes to track coincidences).  In the end, we didn't implement this
because of the traceability it introduces (and I think this would also
be true if we use different packet sizes).

If you take our current mix (no pun intended) of traffic, we have
about 99.99% HTTP and .01% RLOGIN.  I think we'll find that even when
we add more services (FTP/SMTP/etc), we'll still see HTTP as a
staggering percentage.  This then makes it MUCH easier to track
RLOGIN/FTP/SMTP/etc since the connections will be effectively tagged
as they move through the network.

In terms of the QoS idea, we ultimately came up with the idea of
per-node jitter.  We're looking at adding two character-size values to
each layer of the onion: Jitter_Min and Jitter_Max.  These will be
inputs to an always increasing function that will map into some range
(like 0-5000) and will be used to tell a particular onion-router along
a route for how long he may hold up data (jitter it) as it passes him.
Since this is a per layer value and not a global constant, it will not
be trackable (ie, cooperating onion routers will not be able to
compare the values they receive in their layers since any smart onion
creator will vary the values (ie, an onion creator might put the
following tuples in the individual layers: (0,3), (1,6), (0,0), (1,2),
(0,0) -- this would ultimately lead to a data latency of at least 1
and at most 11).  Different services (and different paranoid levels)
might choose different base values and work from there.  It becomes
harder to correlate data then (ie, is a (50,100) a really paranoid
individual or just some low priority data that isn't time sensitive?)

I'm still not really confident that it doesn't leak too much
information, but I think it will leak a lot less than a change in
packet size would (ie, making something like telnet packets really
small in comparison to HTTP).  Not to mention I'm not really happy
about having to potentially store more data at each node (we've
already seen our prototype get deadlocked when someone overwhelmed an
intermediate onion router and refused to extract the data out the
other side and also refused to close the connection) and do a LOT of
buffering.  Ideas/comments would be appreciated :-)

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBM+mz7E8Qx019l0ClAQF2IgQAi1ftpTEkOoJUcs7C+Y2Inc4pfLpqam/S
Tf60yKfygFtJJtL3tVPr4taRA3QpDW7GMKHFi+5fQNfGKG48soAx0E/eXV3gf++G
/ohXb148SZgJA4W0YiG2Jiwf8yGvQexcE5//FxjyohvZaIvD5vQvsOIRcCTGYxsh
NwJFp5TmKtE=
=kt3u
-----END PGP SIGNATURE-----


From majordom  Tue Aug 12 14:20:31 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA13749; Tue, 12 Aug 97 14:20:31 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA13739; Tue, 12 Aug 97 14:20:25 EDT
Date: Tue, 12 Aug 1997 14:20:58 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Size of cells...
Message-Id: <Pine.GSO.3.95.970812135855.18046G-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

All-
	I just wanted to revive the discussion about changing the CELL
size in OR.  Just to recap for those of you out of this discussion,
cells are the fundamental data unit used to ship stuff around within
the OR network.  OR requires guaranteed, in-order delivery of cells
within the network (or notification that the cell carrying pipe has
gone down to proceed with a cleanup operation).  Because of this, we
currently run over TCP/IP sockets (although we could build this on top
of an unreliable protocol such as UDP/IP, but I would rather take
advantage of the power of TCP than reinvent the wheel), but we
considered the possibility of running OR over an ATM/AAL5 network.  To
this end, we standardized on our cells being 48 bytes so we could fit
within an ATM payload.  Of which, 4 bytes are header and 44 bytes are
payload.
	Now we assumed that there would be a good mix (pardon the pun)
of traffic -- both interactive and bulk transfer.  This has not proven
to be the case to date on the OR running here at NRL.  We see over 99%
of the traffic as web related which has a more bulk transfer like
signature.  With the future services to be added including FTP and
SMTP traffic, this does not appear it will change.  In the future, I
would be VERY surprised if we say more than 5 or 10% of all traffic
being interactive sessions.  To this end, it appears that a larger
cell payload size would be more efficient and thus more attractive.
	Add to all of this the fact that most ATM networks that exist
today either are running raw ATM protocols for data/voice, or are
running TCP/IP over the underlying ATM network.  Very few people are
running ATM/AAL5 in place of TCP/IP and this trend does not appear to
be changing.  Some network people conjecture that ATM/AAL5 will never
replace TCP/IP, instead ATM will continue to be utilized for backbone
network with TCP/IP running over it as used today.
	On a different note, we are extremely concerned that
introducing different levels of service, or variable payload lengths
will introduce easy traceability of data through the network (to
insiders, not necessarily outsiders although information may leak out
to them as well).  This will be especially true if only a small class
of services use a particular payload length.  IE, if we had small but
fixed payload length for interactive services and larger but fixed
payload lengths for bulk services, it would easily identify
interactive services.
	We are not addressing volume or timing attacks here (ie,
cooperating onion routers could correlate timing signatures or data
quantities on a particular ACI), but instead size markers.  We have
ideas to help the volume/timing attacks, but those ideas will be
discussed later.  What we are trying to come to grips with now are the
following:

	1) Should we ditch the ATM constraint of 48 byte cells?
	2) Should we maintain fixed-length cells or move to
	   variable length?
	3) Should we allow different classes of service in terms
	   of cell length?  (interactive vs. bulk)
	4) If we enlarge the fixed length payload, to what size
	   should we go? (128, 256, 512 bytes? keeping in mind
	   both interactive and bulk data usage)

Comments would be greatly appreciated!

-Michael


From majordom  Mon Aug 25 18:00:43 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA18519; Mon, 25 Aug 97 18:00:43 EDT
Received: from sbusol.rz.uni-sb.de by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA18513; Mon, 25 Aug 97 18:00:37 EDT
Received: from cs.uni-sb.de (ftp.cs.uni-sb.de [134.96.254.254]) by sbusol.rz.uni-sb.de (8.8.5/8.8.4/8.8.2) with ESMTP id AAA25233 for <onions@itd.nrl.navy.mil>; Tue, 26 Aug 1997 00:00:35 +0200 (METDST)
Received: from fsinfo.cs.uni-sb.de (root@fsinfo.cs.uni-sb.de [134.96.239.10])
          by cs.uni-sb.de (8.8.7/97052600) with ESMTP
          id AAA10549 for <onions@itd.nrl.navy.mil>; Tue, 26 Aug 1997 00:00:34 +0200 (CEST)
Received: from [134.96.113.178] (acc1-178.telip.uni-sb.de [134.96.113.178])
          by fsinfo.cs.uni-sb.de (8.8.7/97070902) with ESMTP
          id AAA22265 for <onions@itd.nrl.navy.mil>; Tue, 26 Aug 1997 00:00:05 +0200 (CEST)
Message-Id: <l03102800b02707986fba@[134.96.113.166]>
In-Reply-To: 
 <Pine.GSO.3.95.970812135855.18046G-100000@banana-jr.itd.nrl.navy.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 25 Aug 1997 12:06:45 +0200
To: Onion Routing List <onions@itd.nrl.navy.mil>
From: Lothar Fritsch <fritsch@fsinfo.cs.uni-sb.de>
Subject: Future OR design Re: Size of cells...
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 20:20 Uhr +0200 12.08.1997, Michael G. Reed wrote:
>All-
>	I just wanted to revive the discussion about changing the CELL
>size in OR.

Well, after some days passed I'll give my $0.02 to it.
It very much looks like OR reached a point where the further design needs
to fit networks or applications it will be used for. If you're mixing ATM,
your cell size is fine. If you're mixing Internet, supposedly a larger cell
size to fit bulk http and ftp transfer would be the right decision. Fitting
telnet and rlogin doesn't deserve a heck lot of attention: first of all,
you measured very little usage of the rlogin OR, and second, besides a
handful of academic people I don't see a mass application of interactive
sessions so you'd even have problems creating the anonymity set to hide the
connections in. Maybe people don't even trust the OR (the router might as
well copy their passwords).
So the only working solution might be sending larger cells containing a
single real data byte.
Another solution could be imagined, but would add some complexity to the OR
network: using the free rlogin cell space to transmit other data. This
involved repackacking cells, and seems to be a complex problem to me.


The way to go might be to specialize OR: a bulk OR for internet load,
custom made ORs for ATM, general TCP/IP OR for internet providers to
anonymize their customers, and real-time-large-throughput OR for protecting
video-on-demand customers. All these services still might run through the
same server to make traffic analysis more expensive.


Lothar Fritsch

--
Lothar Fritsch                        Informatik, Fotografie,
fritsch@fsinfo.cs.uni-sb.de           Internet-Journalist,
http://fsinfo.cs.uni-sb.de/~fritsch/  Neue Medien, Schulungen



From majordom  Tue Aug 26 09:39:51 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA03634; Tue, 26 Aug 97 09:39:51 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA03628; Tue, 26 Aug 97 09:39:43 EDT
Date: Tue, 26 Aug 1997 09:40:16 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Lothar Fritsch <fritsch@fsinfo.cs.uni-sb.de>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Future OR design Re: Size of cells...
In-Reply-To: <l03102800b02707986fba@[134.96.113.166]>
Message-Id: <Pine.GSO.3.95.970826093346.4221G-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Mon, 25 Aug 1997, Lothar Fritsch wrote:
|>Well, after some days passed I'll give my $0.02 to it.

And there was much rejoicing!!!  Finally some input :-)

|>It very much looks like OR reached a point where the further design needs
|>to fit networks or applications it will be used for. If you're mixing ATM,
|>your cell size is fine. If you're mixing Internet, supposedly a larger cell
|>size to fit bulk http and ftp transfer would be the right decision. Fitting
|>telnet and rlogin doesn't deserve a heck lot of attention: first of all,
|>you measured very little usage of the rlogin OR, and second, besides a
|>handful of academic people I don't see a mass application of interactive
|>sessions so you'd even have problems creating the anonymity set to hide the
|>connections in. Maybe people don't even trust the OR (the router might as
|>well copy their passwords).
|>So the only working solution might be sending larger cells containing a
|>single real data byte.

I agree.

|>Another solution could be imagined, but would add some complexity to the OR
|>network: using the free rlogin cell space to transmit other data. This
|>involved repackacking cells, and seems to be a complex problem to me.

Ugh!  Someone here suggested that (he'll remain nameless), and I
soundly beat him over the head at the amount of work he was proposing
for me to do :-)

|>The way to go might be to specialize OR: a bulk OR for internet load,
|>custom made ORs for ATM, general TCP/IP OR for internet providers to
|>anonymize their customers, and real-time-large-throughput OR for protecting
|>video-on-demand customers. All these services still might run through the
|>same server to make traffic analysis more expensive.

This is a *REALLY* good point.  I can imagine several, parallel OR
networks.  One that would service normal bulk transfers
(SMTP/HTTP/FTP/NNTP), one that would support interactive services
(IRC/TELNET), and one that would support massive data (VIDEO/VOICE).
Since they are distinct, they can have different cell sizes (although
the size would be set in stone for each network) to best match the
service type.  The big drawback is that you loose some of the hiding
that you would get if this all went over the same network, but we may
make big wins in the following areas:

	1) Dedicated high-capacity services (video/voice) wouldn't kill
	   other lower-bandwidth services.
	2) Redundancy in network design (ie if one network goes down, the
	   others will keep on running).
	3) Better network design/load use (ie, you may not need an Ultra2
	   with hardware crypto for the interactive sessions that tend to
	   be long with few new connections per day).

I like it!  Comments?

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNALcxE8Qx019l0ClAQE8GgP7B6CwOR+gNjtym6SOgB0iUEMxLdiH7Hqe
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From majordom  Tue Aug 26 12:29:54 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10281; Tue, 26 Aug 97 12:29:54 EDT
Received: from netcom9.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10271; Tue, 26 Aug 97 12:29:46 EDT
Received: from lucky.netcom.com (shamrock@netcom9.netcom.com [192.100.81.119]) by netcom9.netcom.com (8.6.13/Netcom)
	id JAA13279; Tue, 26 Aug 1997 09:29:43 -0700
Message-Id: <3.0.2.32.19970826092816.00711e1c@netcom10.netcom.com>
X-Sender: shamrock@netcom10.netcom.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32)
Date: Tue, 26 Aug 1997 09:28:16 -0700
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
From: Lucky Green <shamrock@netcom.com>
Subject: Re: Future OR design Re: Size of cells...
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
In-Reply-To: <Pine.GSO.3.95.970826093346.4221G-100000@banana-jr.itd.nrl.
 navy.mil>
References: <l03102800b02707986fba@[134.96.113.166]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 09:40 AM 8/26/97 -0400, Michael G. Reed wrote:
>This is a *REALLY* good point.  I can imagine several, parallel OR
>networks.  One that would service normal bulk transfers
>(SMTP/HTTP/FTP/NNTP), one that would support interactive services
>(IRC/TELNET), and one that would support massive data (VIDEO/VOICE).
>Since they are distinct, they can have different cell sizes (although
>the size would be set in stone for each network) to best match the
>service type.  The big drawback is that you loose some of the hiding
>that you would get if this all went over the same network, but we may
>make big wins in the following areas:
>
>	1) Dedicated high-capacity services (video/voice) wouldn't kill
>	   other lower-bandwidth services.

Different routers could offer different published QOS. The user could chose
a path that suits their QOS requirements.

>	2) Redundancy in network design (ie if one network goes down, the
>	   others will keep on running).

Individual routers can go down. Entire networks never should.

>	3) Better network design/load use (ie, you may not need an Ultra2
>	   with hardware crypto for the interactive sessions that tend to
>	   be long with few new connections per day).

I agree on 3), but I think breaking up the mix might greatly facilitate
traffic analysis.

BTW, I agree that you should change the packet size. And congratulations to
deciding to go with SSLeay. It is the best crypto library out there. I hope
the future-rewrite OR code will match SSLeay's portability. :-)

Keep up the good work,

--Lucky Green <shamrock@netcom.com>
  PGP encrypted mail preferred.
  DES is dead! Please join in breaking RC5-56.
  http://rc5.distributed.net/

From majordom  Tue Aug 26 12:42:05 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10762; Tue, 26 Aug 97 12:42:05 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA10699; Tue, 26 Aug 97 12:40:40 EDT
Date: Tue, 26 Aug 1997 12:41:11 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Lucky Green <shamrock@netcom.com>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Future OR design Re: Size of cells...
In-Reply-To: <3.0.2.32.19970826092816.00711e1c@netcom10.netcom.com>
Message-Id: <Pine.GSO.3.95.970826123144.4779B-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 26 Aug 1997, Lucky Green wrote:
|>>	1) Dedicated high-capacity services (video/voice) wouldn't kill
|>>	   other lower-bandwidth services.
|>
|>Different routers could offer different published QOS. The user could chose
|>a path that suits their QOS requirements.

Exactly.

|>>	2) Redundancy in network design (ie if one network goes down, the
|>>	   others will keep on running).
|>
|>Individual routers can go down. Entire networks never should.

Correct -- that is implied as well.

|>>	3) Better network design/load use (ie, you may not need an Ultra2
|>>	   with hardware crypto for the interactive sessions that tend to
|>>	   be long with few new connections per day).
|>
|>I agree on 3), but I think breaking up the mix might greatly facilitate
|>traffic analysis.

I'm not so sure that is the case.  The real question is how well
utilized the network will be.  Even with the different padding
approaches we've come up with, if users aren't using the network, then
it will be more vulnerable.  If we see adequate usage of each of the
parallel networks, then I don't think we loose in the traffic analysis
war, we just don't benefit from having all the traffic together.

|>BTW, I agree that you should change the packet size. And congratulations to
|>deciding to go with SSLeay. It is the best crypto library out there. I hope
|>the future-rewrite OR code will match SSLeay's portability. :-)

Um, yes and no.  I've already pointed out to the SSLeay authors the
fact that there is no direct access to the raw RSA operations without
breaking the API (namely, I need raw, unpadded RSA...not that ugly
PKCS/SSL padding that RSAREF seems so fond of and they duplicated in
SSLeay).  I've been given assurances that support for what I need will
be in the next release (maybe the one after that), so then we're
golden.  On another note, there is a new codebase that hasn't been
sent out yet that correctly implements the mixing function and also
takes care of a REALLY nasty bug in the Solaris version of the system.
This codebase also moves from Solaris threads/mutexs to POSIX
threads/mutexs, so porting to things like Linux should be quite a bit
easier.  This new codebase has been sent to only one other individual
and should be general available in the next day or two.

|>Keep up the good work,

Thanks....keep the input coming :-)

- -Michael

-----BEGIN PGP SIGNATURE-----
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From majordom  Tue Aug 26 19:36:11 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA23948; Tue, 26 Aug 97 19:36:11 EDT
Received: from uni-sb.de by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA23942; Tue, 26 Aug 97 19:36:04 EDT
Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31])
          by uni-sb.de (8.8.7/97052600) with ESMTP
          id BAA14990 for <onions@itd.nrl.navy.mil>; Wed, 27 Aug 1997 01:35:52 +0200 (CEST)
Received: from fsinfo.cs.uni-sb.de (root@fsinfo.cs.uni-sb.de [134.96.239.10])
          by cs.uni-sb.de (8.8.7/97052600) with ESMTP
          id BAA23954 for <onions@itd.nrl.navy.mil>; Wed, 27 Aug 1997 01:35:53 +0200 (CEST)
Received: from [134.96.113.123] (acc1-123.telip.uni-sb.de [134.96.113.123])
          by fsinfo.cs.uni-sb.de (8.8.7/97070902) with ESMTP
          id BAA22674 for <onions@itd.nrl.navy.mil>; Wed, 27 Aug 1997 01:35:29 +0200 (CEST)
Message-Id: <l03102801b0291018ed92@[134.96.113.104]>
In-Reply-To: <3.0.2.32.19970826092816.00711e1c@netcom10.netcom.com>
References: <Pine.GSO.3.95.970826093346.4221G-100000@banana-jr.itd.nrl.
 navy.mil> <l03102800b02707986fba@[134.96.113.166]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 27 Aug 1997 01:10:53 +0200
To: Onion Routing List <onions@itd.nrl.navy.mil>
From: Lothar Fritsch <fritsch@fsinfo.cs.uni-sb.de>
Subject: Re: Future OR design Re: Size of cells...
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 18:28 Uhr +0200 26.08.1997, Lucky Green wrote:
>At 09:40 AM 8/26/97 -0400, Michael G. Reed wrote:
>
>>	2) Redundancy in network design (ie if one network goes down, the
>>	   others will keep on running).
>
>Individual routers can go down. Entire networks never should.

Well, this is an interesting point. OR or MIX networks tend to use chains
of servers. One of the servers going down would shut of a lot of
connections.
And here is where user psychology comes into play: unless you assume some
software module (or even OR / MIX testing protocol) generates random paths
for the OR chains, users might build preferences for certain ORs (e.g. by
only knowing 5 of them and not caring to find more of them). Imagine a
certain OR becoming very popular (remeber anon.penet.fi?) and being used by
60% of the users in their chains. Shutting off this OR would severely
decrease the networks' uptime for the users. Not to mention security risks
created by people always using the same chain of ORs.

 I think it was Ceki G=FClc=FC (I might be wrong here, just too many papers =
do
float around on my desk...) who suggested to include the addresses of the
following two hops into a data packet, along with increasing the number of
ORs used. I personally don't think this increases reliability at all.

Lothar

PS: Did you ever consider an attack where a OR is slowed down or
manipulated so that the TCP/IP connections still exist, but substantially
less data is accepted than sent by the senders? TCP buffers throughout the
OR's should fill up and traffic slow down and stop along the connection's
path ... up to the sender's link. The only way around this seems to be
pseudo traffic from the sender's machine to the 1st OR in the chain as soon
as the 'regular' link doesn't transmit data any more. Any other ideas?

--
Lothar Fritsch                        Informatik, Fotografie,
fritsch@fsinfo.cs.uni-sb.de           Internet-Journalist,
http://fsinfo.cs.uni-sb.de/~fritsch/  Neue Medien, Schulungen



From majordom  Tue Aug 26 21:26:14 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA25299; Tue, 26 Aug 97 21:26:14 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA25289; Tue, 26 Aug 97 21:26:06 EDT
Date: Tue, 26 Aug 1997 21:26:37 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Lothar Fritsch <fritsch@fsinfo.cs.uni-sb.de>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Future OR design Re: Size of cells...
In-Reply-To: <l03102801b0291018ed92@[134.96.113.104]>
Message-Id: <Pine.GSO.3.95.970826211214.5268A-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 27 Aug 1997, Lothar Fritsch wrote:
|>Well, this is an interesting point. OR or MIX networks tend to use chains
|>of servers. One of the servers going down would shut of a lot of
|>connections.

Yes, a link failing does mean that all current connections through it
are immediately lost.  We've looked into ways to delay propagating
this information (it is potentially a flood of information that may
cause an information leak).  Furthermore, if the network cannot
quickly re-adept, then all new connections that are destined to span
that link will fail too.  We're currently having a bit of an argument
about what kind of topology information needs to be distributed and
how it should be distributed.  Personally, I'm for the decentralized
approach where the link state information (*NOT* routing
information...  that's a completely different ball) is sent in-band as
a new cell type.  However, for the short range (ie, time being), I've
been beaten into accepting a less than desirable solution of a
centralized server that will keep the info.  This will have to change
if the OR networks are going to scale to any kind of reasonable size.

|>And here is where user psychology comes into play: unless you assume some
|>software module (or even OR / MIX testing protocol) generates random path=
s
|>for the OR chains, users might build preferences for certain ORs (e.g. by
|>only knowing 5 of them and not caring to find more of them). Imagine a
|>certain OR becoming very popular (remeber anon.penet.fi?) and being used =
by
|>60% of the users in their chains. Shutting off this OR would severely
|>decrease the networks' uptime for the users. Not to mention security risk=
s
|>created by people always using the same chain of ORs.

This brings up the whole issue of how to distribute topology
information, link-state information, public keys, administrative
policies, etc.  As I said above, we have a less than stellar solution
in the draft stage now, and we plan on revisiting this again later to
get a real solution -- these are REALLY BIG problems that need REALLY
GOOD solutions if this project is ultimately going to succeed.  As for
the route generation, if users make that mistake, then there is
nothing we can do...I think people will need to realize that you
*REALLY* have to trust your local proxy and your internet connection
to that proxy...if you don't, you shouldn't be using the system since
it doesn't protect you.  Given that, I'm not too worried about this.

|> I think it was Ceki G=FClc=FC (I might be wrong here, just too many pape=
rs do
|>float around on my desk...) who suggested to include the addresses of the
|>following two hops into a data packet, along with increasing the number o=
f
|>ORs used. I personally don't think this increases reliability at all.

Care to comment (I think he's still on the list :-)?

|>PS: Did you ever consider an attack where a OR is slowed down or
|>manipulated so that the TCP/IP connections still exist, but substantially
|>less data is accepted than sent by the senders? TCP buffers throughout th=
e
|>OR's should fill up and traffic slow down and stop along the connection's
|>path ... up to the sender's link. The only way around this seems to be
|>pseudo traffic from the sender's machine to the 1st OR in the chain as so=
on
|>as the 'regular' link doesn't transmit data any more. Any other ideas?

We've considered a LOT of attacks...there is a paper just detailing
them alone in the works.  It's interesting to note that quite a few of
the ones we've come up with are also vulnerabilities in Pipe-Net.  We
don't necessarily have good solutions to all of them, but then again,
not all of them are realistic attacks either (more info soon).

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNAOCUU8Qx019l0ClAQHzrQP+OLhSORU8qMYlZJfFnGk/iJ3kIkAF5qLY
8xeslPcKl8mCXoo22kyp/iOapZ13xXh6Vx4ucNLGbvl3+886NDgMWAoz/8sVH/rM
rJJrYw8t7yqGLV/28NMOcm6VrlVK82fsnW0yrnVtV+cas2B9Lc0nExyr+uZG7djy
YqWkJitdc7I=3D
=3DWK2Q
-----END PGP SIGNATURE-----


From majordom  Tue Aug 26 22:54:41 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA26225; Tue, 26 Aug 97 22:54:41 EDT
Received: from netcom9.netcom.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA26219; Tue, 26 Aug 97 22:54:33 EDT
Received: from lucky.netcom.com (shamrock@netcom2.netcom.com [192.100.81.108]) by netcom9.netcom.com (8.6.13/Netcom)
	id TAA24366; Tue, 26 Aug 1997 19:54:29 -0700
Message-Id: <3.0.2.32.19970826192717.0069e13c@netcom10.netcom.com>
X-Sender: shamrock@netcom10.netcom.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 b4 (32)
Date: Tue, 26 Aug 1997 19:27:17 -0700
To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
From: Lucky Green <shamrock@netcom.com>
Subject: Re: Future OR design Re: Size of cells...
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
In-Reply-To: <Pine.GSO.3.95.970826211214.5268A-100000@banana-jr.itd.nrl.
 navy.mil>
References: <l03102801b0291018ed92@[134.96.113.104]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

At 09:26 PM 8/26/97 -0400, Michael G. Reed wrote:
>We're currently having a bit of an argument
>about what kind of topology information needs to be distributed and
>how it should be distributed.  Personally, I'm for the decentralized
>approach where the link state information (*NOT* routing
>information...  that's a completely different ball) is sent in-band as
>a new cell type.  However, for the short range (ie, time being), I've
>been beaten into accepting a less than desirable solution of a
>centralized server that will keep the info.  This will have to change
>if the OR networks are going to scale to any kind of reasonable size.

A central server on which all users must rely for such crucial information
as the network state is a Bad Thing. It lends itself to attack, both
spoofing and DoS, provides a single point of failure, etc. This is bad
design. Don't waste time on coding a design that you know to be unsuitable
to the task.

So who do we need to beat up to get them to stop beating you up? :-)

[...]
>This brings up the whole issue of how to distribute topology
>information, link-state information, public keys, administrative
>policies, etc.  As I said above, we have a less than stellar solution
>in the draft stage now, and we plan on revisiting this again later to
>get a real solution -- these are REALLY BIG problems that need REALLY
>GOOD solutions if this project is ultimately going to succeed.

Distributing this information is difficult. Automating the routing process
securely may well be impossible. IMHO, there has to be user involvement.

>  As for
>the route generation, if users make that mistake, then there is
>nothing we can do...I think people will need to realize that you
>*REALLY* have to trust your local proxy and your internet connection
>to that proxy...if you don't, you shouldn't be using the system since
>it doesn't protect you.  Given that, I'm not too worried about this.

I tend to agree.

[...]
>We've considered a LOT of attacks...there is a paper just detailing
>them alone in the works.  It's interesting to note that quite a few of
>the ones we've come up with are also vulnerabilities in Pipe-Net.  We
>don't necessarily have good solutions to all of them, but then again,
>not all of them are realistic attacks either (more info soon).

Indeed, Pipe-net is vulnerable to delay attacks. The solution to this type
of attack is  complex. Still, before discounting any attacks as unlikely,
you may want to bounce them off this list. :-)


--Lucky Green <shamrock@netcom.com>
  PGP encrypted mail preferred.
  DES is dead! Please join in breaking RC5-56.
  http://rc5.distributed.net/

From majordom  Wed Aug 27 16:44:59 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA25247; Wed, 27 Aug 97 16:44:59 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA25160; Wed, 27 Aug 97 16:43:28 EDT
Date: Wed, 27 Aug 1997 16:44:00 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Lucky Green <shamrock@netcom.com>
Cc: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Re: Future OR design Re: Size of cells...
In-Reply-To: <3.0.2.32.19970826192717.0069e13c@netcom10.netcom.com>
Message-Id: <Pine.GSO.3.95.970827164156.6699A-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 26 Aug 1997, Lucky Green wrote:
|>A central server on which all users must rely for such crucial information
|>as the network state is a Bad Thing. It lends itself to attack, both
|>spoofing and DoS, provides a single point of failure, etc. This is bad
|>design. Don't waste time on coding a design that you know to be unsuitable
|>to the task.
|>
|>So who do we need to beat up to get them to stop beating you up? :-)

Some of the preceding messages may have led to misunderstanding of our
approach to redesign.  We weren't deciding primarily about centralized
vs. decentralized solutions to topology information maintenance.  We
wanted to be open to many approaches for distributing dynamic and
static topology information changes, key information changes, etc.
The design decision we have currently agreed on is to simplify the
functional modules comprising the OR systems. Just as we have
separated the proxy and onion creation functions from the
routing-mixing modules, we will separate topology maintenance modules
from the routing-mixing modules too.

Since the r-m module (``r-m'' for routing-mixing) knows the status of
its connections to its neighbors, its obligation is to inform the
topology maintenance module about changes in that status. It is then
up to the topology maintenance modules to distribute this information
in some sensible way.

Note that while the r-m modules are the source of much topology info,
they need nothing more than local neighbor information themselves.
Where this information is needed is at the onion building proxies on
the edges of OR network, because they are the ones that build the
routes. Specifically, onion building proxies must have at least enough
of a complete picture of the network link state to build a route.

We chose this solution since it takes responsibility for topology
maintenance information away from the r-m module to let it focus on
its main task.  On the other hand, we have been considering the
possibility that this modularity should be essentially
conceptual. That the r-m module pass topology info as a different cell
type, just as we pass data cells for individual connections.  This has
the possible advantage of reduced IPC costs between the r-m module and
the topology maintenance module, and also of adding more traffic to
the network to enable better hiding.  But, this solution means that
the routing-mixing module has to understand the topology maintenance
algorithm to decide when and to whom it is appropriate to forward
topology cells. This adds complexity to a security critical part of
our system.

Comments/criticisms on these choices and the advantages of the options
are welcome as always.

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNASRlE8Qx019l0ClAQG4TQP6AqhOB0dv5sTF27mHIJtB0WMmxm+qZQP/
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-----END PGP SIGNATURE-----


From majordom  Thu Aug 28 04:26:29 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA05426; Thu, 28 Aug 97 04:26:29 EDT
Received: from einstein.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA05420; Thu, 28 Aug 97 04:26:23 EDT
Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id BAA23691; Thu, 28 Aug 1997 01:29:53 -0700
Date: Thu, 28 Aug 1997 01:29:53 -0700
Message-Id: <199708280829.BAA23691@einstein.bluemoney.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: onions@itd.nrl.navy.mil
Subject: BSAFE3 for Linux? :-)
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
From: Jeremey Barrett <jeremey@bluemoney.com>
Organization: BlueMoney Software Corp.
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

The core onion router is compiled on Linux, save the linking to the
crypto. Before I finish an SSLeay wrapper, does anyone have BSAFE3
for Linux? It would make testing easier, less variables and all
that. 

Thanks,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNAU24C/fy+vkqMxNAQEUBAQAiZLfDI3fzANVtEJUZZREK1yDM6Rd+MgR
AZLqBfbcViS+hwiD4PBjHc0eW9ib+EngEQ3jWka1+cav4Y9bzkeIx2c2UB+t1xnG
s9DbxvNzWBadwgMjWrIYqWg7+1UUa85TnpNxWY7+yP8h4JT0UzBRRVhUWScjWCI8
S76DdOVbNwc=
=4HLQ
-----END PGP SIGNATURE-----

From majordom  Thu Aug 28 18:52:01 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA05354; Thu, 28 Aug 97 18:52:01 EDT
Received: from einstein.bluemoney.com by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA05348; Thu, 28 Aug 97 18:51:56 EDT
Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id PAA01352; Thu, 28 Aug 1997 15:55:37 -0700
Date: Thu, 28 Aug 1997 15:55:37 -0700
Message-Id: <199708282255.PAA01352@einstein.bluemoney.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: onions@itd.nrl.navy.mil
Subject: BER RSA keys
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
From: Jeremey Barrett <jeremey@bluemoney.com>
Organization: BlueMoney Software Corp.
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

I've written a wrapper emulating BSAFE calls using SSLeay (so far
for DES-CBC, RSA, DH, SHA1, and MD5, everything used in the onion
routers). The last step is to figure out BER-encoded RSA keys,
so I can turn them into bignums for SSLeay. If anyone knows
what the encoding looks like off the top of their heads, please
let me know.

I have BSAFE on another platform, so at worst I'll write some code
to generate both BER and non-BER keys, and compare.

BTW, the core router now links cleanly on Linux, so all I need is to 
decode the RSA keys and I can start dumping core.

Thanks,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNAYB3y/fy+vkqMxNAQEAJQP9FvOhO0Q1nseYqe31QlA1fzq+r/6z/Oa9
ID6y5v7u1vipHjQkh7s+YWitV8dA3X1LnK3O3s8mSychIrOhWRjpbj7H3k5Gqc41
liqHKgSgYDsyKOnaCTg0/fXM2VyXb+R6I9DnWBJD183lra161cg0GJfLWXgXgGA+
RY+4XciMhyU=
=Bf0X
-----END PGP SIGNATURE-----

From majordom  Fri Aug 29 07:44:23 1997
Return-Path: <majordom>
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA15080; Fri, 29 Aug 97 07:44:23 EDT
Received: from banana-jr.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1)
	id AA15074; Fri, 29 Aug 97 07:44:16 EDT
Date: Fri, 29 Aug 1997 07:44:48 -0400 (EDT)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Jeremey Barrett <jeremey@bluemoney.com>
Cc: onions@itd.nrl.navy.mil
Subject: Re: BER RSA keys
In-Reply-To: <199708282255.PAA01352@einstein.bluemoney.com>
Message-Id: <Pine.GSO.3.95.970829071905.8040B-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, 28 Aug 1997, Jeremey Barrett wrote:
|>I've written a wrapper emulating BSAFE calls using SSLeay (so far
|>for DES-CBC, RSA, DH, SHA1, and MD5, everything used in the onion
|>routers). The last step is to figure out BER-encoded RSA keys,
|>so I can turn them into bignums for SSLeay. If anyone knows
|>what the encoding looks like off the top of their heads, please
|>let me know.
|>
|>I have BSAFE on another platform, so at worst I'll write some code
|>to generate both BER and non-BER keys, and compare.

According to my BSAFE manuals..."The standard description of
information is known as Basic Encoding Rules, or BER, which is a
product of Open Systems Interconnection of the ANSI X.200 series.  BER
is defined in X.209."  It looks like X.209 is based on X.208 which is
ASN.1, which (correct me if I'm wrong) is what SSLeay uses (or is
capable of using).  Probing around RSA-land will get you to
http://www.rsa.com/rsalabs/pubs/PKCS/ which includes links to "A
Layman's Guide to a Subset of ASN.1, BER, and DER" written by Burton
S. Kaliski.  A more useful publication, "Some Examples of the PKCS
Standards" gives quick examples of the format of both public and
private keys which have been BER encoded...THIS IS WHAT YOU WANT :-)
It may be that you can use SSLeay's ASN.1 routines without any real
work, or you may need to pick apart the keyfiles directly...not sure.

Remember, my key-files include multiple keys that are stacked one
after another in the form ULONG length, unsigned char data[length],
unsigned char pad.  Where pad is 0-4 bytes to make the next field in
the file long aligned.  This length fields are 32-bit longs stored in
network order.

|>BTW, the core router now links cleanly on Linux, so all I need is to 
|>decode the RSA keys and I can start dumping core.

Ugh!  That was not very punny...good luck

- -Michael

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNAa2NE8Qx019l0ClAQFSJwP/YlMt+OPPwSCs1eeTy9IDVZTzooHig9yk
irlDGjJ/WNnxEUDect653W7pTRNfBlNF1Cdexs6ZrHgUS/hDtBlGxh/MMCsaToem
CpLtEgQosmGgxoi0j2t7MU48ul97xqeFVRtluhPjRtehWUv8Plen7kYw1MgL/FNS
2QoFcheJSJg=
=eI19
-----END PGP SIGNATURE-----


From owner-onions  Tue Dec 16 12:36:21 1997
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id MAA03625
	for onions-outgoing; Tue, 16 Dec 1997 12:35:28 -0500 (EST)
Received: from banana-jr.itd.nrl.navy.mil (banana-jr.itd.nrl.navy.mil [132.250.80.211])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id MAA03614
	for <onions@itd.nrl.navy.mil>; Tue, 16 Dec 1997 12:34:54 -0500 (EST)
Date: Tue, 16 Dec 1997 12:34:53 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: New code tomorrow!
Message-ID: <Pine.GSO.3.95.971216123225.20026K-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

All-
	There will be a new code release (the proof-of-concept system)
that corrects a few bugs that we've had reported from our testers.
This will probably be the last update on this code since development
has now begun on the next generation system.  Full specs on the new
system will be forthcoming after the holidays.
	Those who have received source and binaries in the past will
receive personal email with the name of the new tar file to FTP.  If
you are one of the active nodes in the network, please upgrade your
node as soon as possible.  Thanks!

-Michael


From owner-onions  Tue Dec 16 16:39:15 1997
Received: (from majordom@localhost)
	by itd.nrl.navy.mil (8.8.8/8.8.8) id QAA08962
	for onions-outgoing; Tue, 16 Dec 1997 16:37:31 -0500 (EST)
Received: from banana-jr.itd.nrl.navy.mil (banana-jr.itd.nrl.navy.mil [132.250.80.211])
	by itd.nrl.navy.mil (8.8.8/8.8.8) with SMTP id QAA08953
	for <onions@itd.nrl.navy.mil>; Tue, 16 Dec 1997 16:36:58 -0500 (EST)
Date: Tue, 16 Dec 1997 16:36:59 -0500 (EST)
From: "Michael G. Reed" <reed@itd.nrl.navy.mil>
Reply-To: "Michael G. Reed" <reed@itd.nrl.navy.mil>
To: Onion Routing List <onions@itd.nrl.navy.mil>
Subject: Looking for 'porters'
Message-ID: <Pine.GSO.3.95.971216163009.20608B-100000@banana-jr.itd.nrl.navy.mil>
X-Personal: False
X-Anonymous: False
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-onions@itd.nrl.navy.mil
Precedence: bulk

All-
	Now that we are starting the next generation code, we will be
trying to support as many platforms as possible.  In house, we are
developing against:

	sparc Solaris 2.4, 2.5.1, 2.6
	sparc SunOS 4.1.3u1
	hppa  HPUX 10.00
	rs68k AIX 4.1.3
	i386  BSDI 3.0
	i386  Red Hat Linux 2.4

Our primary development platforms are Solaris 2.5.1 & Linux 2.4.  We
hope to add a i386 NetBSD/OpenBSD/FreeBSD set of machines as well, but
that is on temporary hold.

WHAT WE ARE LOOKING FOR: People who are interested enough in the
project to dedicate some time porting the code to other platforms
(either other OS's, versions of OS, or hardware platform).  Please
respond to onion-info@itd.nrl.navy.mil if you are interested in giving
us a hand.

-Michael


